[01:21] <lucent> smb: thanks for "breaking it down" to me I find that helpful, those messages are confusing to me without the explanation
[03:36] <lucent> ping?
[03:36] <lucent> could use advice about getting more detailed debug info
[06:19] <MTecknology> http://qdb.us/224378
[06:24] <MTecknology> Thought you guys might enjoy that one a little.
[06:37] <ikepanhc> well, this story tells us that installing openssh-server on my desktop is very important
[11:37] <tseliot> cking_: is there a reason why you didn't include this patch in Maverick's kernel? http://pastebin.ubuntu.com/507154/
[11:59] <cking_> tseliot, 'cos it's only just been accepted upstream, and I was waiting to see if it was the best solution
[12:00] <cking_> it cycled a few changes and is expected to land mid october
[12:01] <tseliot> cking_: ok, is the patch fine as it is on pastebin? 
[12:02] <tseliot> for 2.6.35, that is
[12:02] <cking_> nope, I will submit it as a SRU once I'm sure it's landed in acpica 
[12:04] <tseliot> cking_: I'm asking only because I'd like to include it in my kernel (not in maverick). Can you point me to a more updated version of the patch, please?
[12:05] <cking_> tseliot, I'll mail you the patch
[12:05] <tseliot> cking_: thanks a lot
[12:07] <cking_> sent
[14:06] <JFo> going to be out a bit this morning... serious insomnia issues last night. medication finally deciding to kick in it seems
[14:06] <JFo> only 8 hours late
[14:23] <smb> pmatulis, Re: LVM, tried a few things with the current lucid kernel and lvm and did not see any issues. There has been someone mentioning an error message which would be fixed by a patch currently also missing in lucid. But I was not able to reproduce it.
[14:35] <ogra_ac> ogasawara, tgardner, hey
[14:36] <tgardner> ogra_ac, dude
[14:36] <ogra_ac> tgardner, dod cooloney already contact you ?
[14:36] <ogra_ac> *did
[14:37] <tgardner> ogra_ac, about what?
[14:37] <ogra_ac> we have an x-loader change for omap4 that requires an in-sync kernel upload
[14:37] <ogra_ac> wiht a small patch
[14:37] <cooloney> tgardner, yeah, just wanna talk with you
[14:37] <cooloney> ogra_ac, we need to make sure the audio patch will upload 
[14:37] <ogra_ac> release team is fine with omap4 changes at this time (we made that clear in advance)
[14:37] <lag> JFo: Where is the most recent top50?
[14:37] <tgardner> cooloney, I was just about to upload your ASOC changes.
[14:38] <ogra_ac> the audio patch can go in worst case as sru its not as critical as the booting
[14:38] <cooloney> tgardner, yeah, i was also just got another important patch fixing the display issue today
[14:38] <cooloney> will post it out soon
[14:38] <ogra_ac> tgardner, hold on then, we just got another (way smaller) patch from TI Nice
[14:39] <tgardner> cooloney, ogra_ac: I've pushed to the git repo, but haven't uploaded. I'll just wait until I see your next patch set?
[14:40] <cooloney> tgardner, thanks a lot. please wait for a while for my post
[14:40] <tgardner> cooloney, will do
[14:40] <cooloney> tgardner, thanks a lot, man
[14:40]  * ogra_ac hugs tgardner 
[14:40] <tgardner> ogra_ac, no hugging in the kernel team. 
[14:41] <tgardner> we let dholbach take care of all our hugging duties :)
[14:43] <ogra_ac> lol
[14:48] <lag> I think we should have a prettier 'hugger'
[14:48] <lag> tgardner: Where is the latest and greatest Top50?
[14:50]  * cooloney think kissing is more popular than hugging in kernel team. lol
[14:50] <pmatulis> smb: ok.  fyi, henninge is the warthog that was bitten
[14:53] <lag> cooloney: Remind me not to share a room with you at sprint
[14:53] <lag> apw: Top50?
[14:54] <lag> Someone, anyone?
[14:54] <lag> I have this one: http://reports.qa.ubuntu.com/reports/ogasawara/kernel-buglist-top50.html
[14:54] <lag> But it appears to be out of date: May 26 2010 0:18 UTC
[14:55] <bjf> lag: http://reports.qa.ubuntu.com/reports/jfo/kernel-Top50.html
[14:56] <lag> That's better
[14:56] <lag> Thanks Brad
[14:56] <bjf> lag: look at: https://wiki.ubuntu.com/Kernel/Tagging
[14:56] <bjf> lag, from there is the link to what needs to be reviewed as well as the top 50
[14:57] <lag> Lovely, thanks!
[15:10] <ogra_ac> diwic, so what would you propose wrt sound on omap4/panda ?
[15:11] <ogra_ac> do you think calling alsactl init is to hackish ?
[15:12]  * ogra_ac thinks its the least ugly workaround
[15:13] <diwic> ogra_ac, are you running pulseaudio at all?
[15:14] <ogra_ac> diwic, all i do is put the file into /usr/share/alsa/init, apply the one line patch to 00main and put alsactl init into rc.local (so it gets executed on boot)
[15:14] <ogra_ac> the whole rest of the system is completely unmodified
[15:14] <ogra_ac> so yes, pule works fine
[15:14] <ogra_ac> *pulse
[15:15] <ogra_ac> note that all sound is compiled in in this kernel
[15:15] <ogra_ac> no modules here
[15:15] <diwic> ogra_ac, so pulse saves and restores volumes, enabling users to change it on the fly. But then it can't handle all the crazy control names this chip has
[15:15] <ogra_ac> right
[15:16] <ogra_ac> and device 0 isnt linked up to a codec by default
[15:16] <ogra_ac> pules only uses device 0 by default
[15:16] <ogra_ac> *pulse
[15:16] <diwic> ogra_ac, so are there any volume controls that pulse actually control?
[15:17] <diwic> ogra_ac, have you written a custom PA mixer profile?
[15:17] <ogra_ac> it controls hw 0,0 once alsa is active
[15:17] <ogra_ac> no
[15:17] <ogra_ac> i didnt touch pulse
[15:17] <ogra_ac> i only initialize alsa 
[15:17] <diwic> ogra_ac, I'm just trying to figure out what pulseaudio should do and what alsactl init should do here, to make sure they don't collide
[15:17] <ogra_ac> one of these controls lins hw 0,0 to a codec it seems
[15:18] <ogra_ac> *links
[15:18] <ogra_ac> https://bugs.edge.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/637947/+attachment/1673694/+files/omap4
[15:18] <ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed]
[15:19] <ogra_ac> (dont ask me which though, i just took TIs .conf file and adapted it to an init file)
[15:19] <ogra_ac> the way TI does it currently is to hack up default.pa
[15:20] <ogra_ac> and to use an amixer shellscript 
[15:20] <diwic> ogra_ac, so yes, try alsactl init, that would probably be best
[15:20] <ogra_ac> using the "init way" i dont need to touch pulse at all
[15:21] <diwic> ogra_ac, after that, test if you can modify volume in pulse, that it actually affects playback volume, and that the new volume is remembered across reboots
[15:21]  * ogra_ac tries to find a way to call it from a udev rule though
[15:21] <diwic> um, that should be easy I think
[15:21] <ogra_ac> diwic, it definitely controls it, i'm not sure its persistent over reboots
[15:22] <diwic> RUN+="alsactl init"
[15:22] <ogra_ac> diwic, well, there is not much info the soundcard exposes, i want thet rule to only affect this card indeed
[15:22] <ogra_ac> heh
[15:22] <ogra_ac> yeah, i know what to do to exec it 
[15:22] <ogra_ac> but if i want the rule in libasound2 it needs to be specific enough to not call it for all sound devices
[15:23] <ogra_ac> and there are not many things exposed to udev it seems 
[15:23] <diwic> aha, but it should be something in sysfs you could use?
[15:23] <ogra_ac> that would allow me to distinguish the parent device 
[15:24] <ogra_ac> prob is that the sysfs tree just uses soc-audio as parent
[15:24] <diwic> I think you usually trigger on /dev/snd/controlC0 
[15:24] <ogra_ac> right
[15:24] <ogra_ac> but thats to general for my taste 
[15:24] <ogra_ac> i dont want to call the rule for intel hda :)
[15:24]  * ogra_ac goes digging
[15:25] <ogra_ac> would you mention at the bug that the alsactl init way looks ok from a sound guy's perspective ?
[15:25] <ogra_ac> (so i can get an sru)
[15:26] <diwic> 80-alsa.rules calls alsa-utils
[15:26] <ogra_ac> yep
[15:28] <diwic> look at /sbin/alsa-utils , function preinit_levels_on_card - seems to be a place where you can put in hacks? ;-)
[15:28] <ogra_ac> heh, thanks 
[15:29]  * ogra_ac tests reboot persistence now
[15:32] <ogra_ac> yay, works fine :)
[16:40] <ogra> tgardner, so if cooloneys patch hits the git tree, feel free to upload, i just pushed the x-loader patch 
[16:42] <tgardner> ogra: in progress
[16:44] <ogra_ac> tgardner, err, bryan just says its not in the git tree yet
[16:45] <tgardner> ogra: like I said, its in progress. I'll get it pushed soon, then upload thereafter.
[16:45] <ogra_ac> ah, it just only hit the ML
[16:45] <ogra_ac> ok, thanks
[16:45]  * ogra_ac clams down a bit :)
[16:45] <ogra_ac> (calms too)
[16:45] <rsalveti> tgardner: thanks :-)
[16:47] <tgardner> ogra, rsalveti: pushed (you'll need to rebase). I'll upload in a bit.
[16:49] <rsalveti> tgardner: cool, thanks a lot
[16:49] <rsalveti> tgardner: we own you a beer for sure
[16:50] <tgardner> rsalveti, :) I'm having one as we speak.
[16:51] <rsalveti> tgardner: oh, I wish I could haha
[16:51] <rsalveti> but we're at TI
[16:51] <rsalveti> we're all dressed and behaving well
[16:52] <tgardner> rsalveti, I guess thats the advantage of working at home.
[16:52] <tgardner> I'm neither dressed, nor do I behave well.
[16:52] <rsalveti> tgardner: for sure
[16:53] <rsalveti> hehe
[16:59] <manjo> tgardner, any thoughts on the mail I sent you regarding the 2 slots ?
[17:00]  * cooloney just crashed his macbookpro, since it is lucid.
[17:00]  * cooloney is upgrading it to maverick, shame
[17:02] <tgardner> manjo, patience lad. I referred it to pgraner.
[17:02] <manjo> :)
[17:03] <pgraner> manjo, schedule is not set yet I've got it on the list
[17:03] <manjo> pgraner, thanks
[17:11] <cking_> ah, better do some blueprints myself
[17:20]  * cking_ tries to figure out how much H/W he needs to take to the office tomorrow
[17:21] <cking_> eek, too much
[17:21] <lag> When bisecting, is there any way to make the builds faster?
[17:21] <tgardner> cking_, bring it in a roller bag
[17:21] <cking_> roller bag(s)
[17:21] <tgardner> lag, nap while building
[17:22] <cking_> heh, no multi tasking then?
[17:22] <bjf> lag, aren't you using the "--build-faster" flag?
[17:22] <penguin42> lag: -j n on make or DEB_BUILD_OPTIONS=parallel=n  for parallel builds
[17:22] <lag> A user has mentioned creating a script which configures the .config for current HW
[17:22] <lag> Thus only building necessary functionality 
[17:23] <lag> Feasible? 
[17:24] <cooloney> lag: maybe create some STAMP file in debian build directory
[17:24] <lag> To do what?
[17:24] <cooloney> i was just told before, never tried that
[17:25] <lag> But what would it achieve?
[17:25] <cooloney> tgardner, cking_ or bjf might know that 
[17:26] <cooloney> lag: do you wanna to just build some specific driver files after your whole building?
[17:26] <tgardner> lag, you can rebuild fairly quickly by removing the stamp file
[17:26] <cooloney> tgardner: yeah, i mixed them
[17:27] <lag> tgardner: I have done that in the past, but it won't work for large diff bisecs for ~1yr
[17:27] <cooloney> lag: oh, that large change won't help build faster.
[17:28] <lag> Which is my point
[17:28] <cooloney> lag: that's painful. maybe building on our build machine?
[17:45] <lag> tgardner: Can you install the latest kernel-package on our build machine please?
[17:45] <tgardner> lag, wtf are you talking about?
[17:45] <lag> tgardner: I don't know how to say it any clearer :)
[17:46] <tgardner> lag, in a schroot?
[17:46] <lag> apt-get install kernel-package 
[17:46] <lag> I am currently in an i386 chroot yes
[17:46] <tgardner> lag, which schroot? maverick? lucid? 
[17:47] <lag> Maverick please
[17:51] <tgardner> lag, installed.
[17:52] <tgardner> lag, why are you using this? I'm not particularly interested in supporting make-kpkg
[17:53] <lag> tgardner: I'm building a Linus kernel
[17:55] <cooloney> tgardner: in the cross compiling patch you just pushed into our tree, there is a typo in the comment
[17:55] <cooloney> dpk- should be dpkg-
[17:55] <tgardner> cooloney, um, what?
[17:56] <tgardner> cooloney, I'll get apw to fix it.
[17:56] <cooloney> tgardner: np, :)
[17:56] <tgardner> cooloney, I really want him to add it the debian commonization
[17:57]  * manjo sees trouble ahead with Maverick on Toshiba NB305... 
[17:58] <cking_> manjo, most toshiba machines are problematic
[17:58] <manjo> yep
[17:59] <manjo> this one especially coz we are hung on splash screen
[17:59] <tgardner> cking_, dude, you coming to Millbank tomorrow?
[18:01] <apw> cooloney, you need some apple juice
[18:02] <ogra_ac> apw, do i need to take care (we're about to leave for lunch)
[18:02] <apw> ogra_ac, the error is in a comment ... nothing to worry about
[18:03] <ogra_ac> apw, i meant about the apple juice 
[18:04] <apw> ogra_ac, heh no ... 
[18:04]  * cooloney likes apple juice,
[18:04] <manjo> cooloney, try it with titos 
[18:05] <cking_> tgardner, yep, I'm packing my bags right now
[18:05] <cking_> had a hospital appointment today, so that threw the spanner in the works 
[18:06] <cooloney> manjo: what's titos?
[18:06] <manjo> cooloney, fine vodka made in Austin 
[18:06] <cking_> rats, not enough room for lego auto-finger
[18:07] <manjo> cking_, is it the same spanner apw keeps referring to ? 
[18:07] <cooloney> apw: for cross compiling my ti-omap4, i just need to run dpkg-buildpackage -B -aarmel?
[18:07] <cking_> manjo, possibly
[18:07] <cooloney> manjo: great, man. let's drink tonight.
[18:08] <manjo> :)
[18:08] <cking_> hrm, my 10Kg transformer is too big to pack. 
[18:10] <apw> cooloney, maybe :)
[18:11] <tgardner> cooloney, echo "dpkg-buildpackage -B -aarmel"|schroot -c maverick-amd64
[18:11] <jcastro> kernel guys submitting blueprints: stop for a minute please!
[18:11] <tgardner> cooloney, turn off tools building
[18:11] <jcastro> we need to fix your naming convention
[18:11] <tgardner> jcastro, whick kernel guys? smb?
[18:12] <jcastro> andy, bader so far.
[18:12] <smb> I am not doing anything anymore
[18:12] <tgardner> jcastro, his name is spelled 'smb'
[18:12] <jcastro> but if you're working on them I am sending a mail to -devel in a minute so we don't waste your time
[18:12] <jcastro> woo, I'll fix them for you
[18:12]  * cking_ postpones to tomorrow then
[18:13] <cooloney> tgardner and apw, got it, building on server now
[18:27] <bjf> vanhoof, around?
[18:32] <jcastro> ok, sorry for the confusion, I've fixed the blueprints, mail sent to -devel explaining it
[19:17] <fjohnber> names
[19:24] <JanC> bah, my gigabit ethernet NIC only works at 100 Mbit/s, seems like that's a common & recurring issue with the e1000e driver?  :-(
[19:29] <jcrigby> bjf: ping?
[19:29] <bjf> jcastro, hi
[19:29] <bjf> jcrigby, sorry, hi
[19:30] <bjf> jcastro, just ignore me, nothing to see here
[19:30] <jcrigby> bjf, in your kernel team notes it says something about queuing patches for Maverick SRU
[19:31] <bjf> jcrigby, which notes are you referring to? and yes we are
[19:31] <jcrigby> meeting notes from kernel team list
[19:31] <jcrigby> As mentioned last week, we've been queuing patches for Maverick SRU which includes the latest 2.6.35.5, 2.6.35.6, and 2.6.35.7 stable updates.
[19:32] <jcrigby> quote^^
[19:32] <bjf> ah yes,
[19:32] <jcrigby> but I don't see those in git
[19:32] <bjf> jcrigby, ogasawara, probably has them queued in her personal repo
[19:32] <jcrigby> is there a different tree for this?
[19:33] <jcrigby> oh she is here
[19:33] <ogasawara> jcrigby: yep, not pushed the official Maverick repo in case some last minute patches need to get applied and uploaded I didn't want to have to deal with the hundreds of stable patches
[19:33] <jcrigby> I was looking for wrong nick
[19:34] <bjf> jcrigby, git:/kernel.ubuntu.com/git/ogasawara/ubuntu-maverick.git
[19:34] <jcrigby> ogasawara, bfj: ok I see now
[19:35] <jcrigby> so if I wanted to work ahead I could do a new linaro tree based on that, but of course it might change
[19:35] <ogasawara> jcrigby: Am actually getting ready to re-base my tree to be against the latest official Maverick tree (had some last minute patches come in this morning that need to go in the day-0 upload)
[19:35] <jcrigby> so what is target day for day-0
[19:35] <cooloney> ogasawara: is the stable rebasing necessary for ti-omap4, do you think? 
[19:35] <jcrigby> we want to do one last linaro based on your day-0
[19:36] <ogasawara> jcrigby: hopefully Oct 10 is the target day for day-0.  ie they'll officially release Maverick and then approve the day-0 upload right after.
[19:37] <jcrigby> ok, thanks
[19:38] <ogasawara> jcrigby: I'm finishing up some test builds for the day-0 patch set and then will re-push to the official Maverick linux master
[19:38] <ogasawara> jcrigby: I can ping you when it's ready so you can get a head start
[19:39] <jcrigby> ogasawara, thanks!
[19:40] <ogasawara> cooloney: I haven't been touching the ti-omap4 branch unless requested by yourself or others (ie I've not been automatically applying the stable patch sets to the ti-omap4 branch)
[19:41] <ogasawara> cooloney: and for the most part, I've been letting tgardner maintain the ti-omap4 branch
[19:41] <cooloney> ogasawara: yeah, i understand. i will try to rebase stable things after your work. 
[19:41] <ogasawara> cooloney: ack
[19:41] <ogasawara> cooloney: thanks
[19:42] <cooloney> ogasawara: since there are some important arm related fixing in stable releasee
[21:06] <mpoirier> bjf: do you know if you absolutely have to be part of the kernel team to pull something from zinc ?
[21:07] <bjf> mpoirier, depends how you are trying to pull something, but anyone should be able to access git://kernel.ubuntu.com
[21:08] <mpoirier> will someone from linaro be able to get a pull request hosted on kernel.ubuntu.com ?
[21:09] <bjf> mpoirier, i don't know what the rules are for that but I think so
[21:10] <mpoirier> bjf: on zinc, under /srv/kernel.ubuntu.com/git/ubuntu/, we only have references for ubuntu trees.
[21:11] <mpoirier> how hard/feasible is it to add the linaro tree ?
[21:14] <bjf> mpoirier, the linaro tree is a topic branch in the maverick tree
[21:16] <mpoirier> bjf: ti-omap4 is also a topic branch in maverick
[21:16] <bjf> mpoirier, you are correct
[21:16] <mpoirier> bjf: and they have to go through the SRU process if they want to add something in there.
[21:16] <bjf> mpoirier, still don't get your point
[21:17] <mpoirier> bjf: when tim and I talked about the ftrace feature, we agreed to put it in the linaro tree.
[21:18] <mpoirier> bjf: that is all I want to do.
[21:19] <mpoirier> bjf: I was under the impressin that having a pull request for the linaro topic branch in ubuntu would subject me to the SRU process.
[21:19] <mpoirier> bjf: and if I used their tree, I wouldn't.  I could be mistaking.
[21:22] <bjf> mpoirier, what about using git://git.linaro.org/kernel/linux-linaro-2.6.35.git?
[21:23] <bjf> mpoirier, cloning it in your public area on zinc, apply your patches there and submit a pull request from it?
[21:25] <mpoirier> bjf: hold on a sec, checking something...
[21:26] <mpoirier> bjf: this morning i tried multiple time to get git://git.linaro.org/ubuntu/linux-linaro.git
[21:26] <mpoirier> it failed pathetically.
[21:26] <mpoirier> but it think it was a connectivity issue 'cause now it works.
[21:27] <mpoirier> I was trying to find other ways to do just that.
[21:27] <mpoirier> bjf: you can void the last 10 minutes from your memory.
[21:28] <bjf> mpoirier, heh
[21:41]  * ogasawara lunch
[22:05] <mpoirier> bjf: now I remember what the problem was...
[22:05] <mpoirier> bjf: you can't git clone  git://git.linaro.org/ubuntu/linux-linaro.git from zinc
[22:07] <mpoirier> bjf: would you have a suggestion ?
[22:07] <bjf> mpoirier, do you want to end up with a pull request against the official linaro kernel or the linaro topic branch in maverick (and I don't know what the diff between the two is)
[22:08] <mpoirier> official linaro kernel.
[22:08] <bjf> mpoirier, then I'd probably make a local clone and then rsync that git tree to my public area on zinc and then I can clone from that
[22:09] <bjf> mpoirier, it's kind of round-about but it would work
[22:09] <mpoirier> can you rsync from tangerine ?
[22:09] <bjf> mpoirier, i think you can but you would have to give it a try to know for sure
[22:10] <mpoirier> bjf: ya, I was about to write... ok I'll give it a shot.  I wasn't sure is there wasn't another way.
[22:10] <mpoirier> bfj: rsync it is then.
[22:19] <cnd> apw, good news!
[22:19] <cnd> someone posted a patch to a utouch bug that enables multitouch support on synaptics trackpads
[22:19] <cnd> real multitouch
[22:20] <cnd> and I think I can fix up the patch so that we can make things work properly AND allow use of the entire touchpad surface!
[22:21] <Sarvatt> cnd: do you lose tapping? that's kind of the deal breaker, can't imagine using any of my laptop touchpads with the buttons
[22:21] <cnd> Sarvatt, no loss of tapping
[22:21] <Sarvatt> nice!
[22:22] <cnd> it's all in my head right now, how to make this work though
[22:22] <cooloney> cnd, cool man.
[22:22] <cnd> so I need to sit down and try it out
[22:22] <cooloney> cnd, so we can use it in macbook pro 
[22:22] <cnd> cooloney, unibody macs have their own MT capable driver already
[22:23] <cnd> so unless you're thinking of a rather old macbook pro, this isn't relevant
[22:23] <cnd> my idea is that with MT support you do two things:
[22:23] <cnd> 1. you have single touch emulation where the first touch on the touchpad controls the cursor
[22:23] <cooloney> cnd, ok, i just upgrade my mbp to maverick
[22:24]  * Sarvatt hopes the person that posted the patch agrees to copyright assignment
[22:24] <cnd> 2. if the first touch is in the button area as a button goes down, then the touch disappears
[22:24] <cnd> Sarvatt, this is kernel code, no assignment needed :)
[22:25] <cnd> if you implement both of those, I think you can get all the functionality of the touchpad back
[22:25] <cnd> and add in support for two finger scrolling and the like
[22:26] <cooloney> cnd, most of this work are in which part of our user space?
[22:26] <cnd> cooloney, what I'm talking about right now is in psmouse in the kernel
[22:26] <cnd> we don't have to touch userspace
[22:27] <cnd> one might make the argument that code for part 2 shouldn't be in the kernel
[22:27] <cnd> but I'm not convinced quite yet
[22:28] <cooloney> cnd, got it.
[22:29] <cooloney> you said unibody macs have the MT version psmouse driver in kernel?
[22:29] <cnd> they have bcm5984
[22:30] <cnd> which has MT support since lucid
[22:30] <cooloney> ok, so can we enable MT on my unibody mbp in Maverick, how?
[22:31] <cnd> it's already there, but the only app we have enabled out of the box on maverick is unity
[22:32] <cooloney> cnd, got it. man
[23:05] <cnd> I can confirm with my own eyes that we can do MT with the synaptics driver
[23:05] <cnd> :)
[23:05] <cnd> but it needs to be fixed up
[23:05] <cnd> I patched my psmouse module and tested it out, but it only emitted MT events instead of emitting both MT and ST (single touch) events
[23:05] <cnd> so X didn't know what to do
[23:05] <cnd> and the touchpad became useless :)