[00:26] <RAOF> Sarvatt: Doh!  If that doesn't fully fix your touchpad you might want to ping whot; he's under the impression that'll fix his redhat bug :)
[21:31] <sforshee> cnd, I'm doing some debug prints in x-x-i-s for the bcm5974 s3 problem. My assumption is that all events from the touchpad will go through the loop in EventReadHwState. Is that correct?
[21:31] <cnd> yeah
[21:32] <sforshee> okay, so here's what I see then...
[21:32] <sforshee> UninitializeTouch is called on the way down, InitializeTouch is called coming back up
[21:32] <sforshee> no events come in before I touch the touchpad
[21:32] <sforshee> yet it's still messed up
[21:33] <cnd> maybe the state is still somewhat screwed up even after uninit and init?
[21:33] <sforshee> that would be my guess
[21:34] <sforshee> so resetting num_touches isn't enough I guess
[21:36] <cnd> sforshee, what are you seeing when you hit the bug?
[21:37] <sforshee> basically most things kind of acts like I have one additional finger down, except for moving the pointer which works fine
[21:37] <sforshee> so a click generates a right click
[21:37] <sforshee> a 2-finger drag moves windoes
[21:37] <sforshee> *windows
[21:38] <sforshee> etc.
[21:39] <sforshee> actually the click behavior with one finger is inconsistent, sometimes I get right click, sometimes left click
[21:39] <sforshee> two-finger drag very consistently moves windows though
[21:40] <cnd> that's odd
[21:41] <cnd> I'm wondering if there is an issue with mtdev
[21:41] <sforshee> hmm, now something is wedged
[21:41] <cnd> here's my theory
[21:42] <cnd> mtdev takes untracked touches
[21:42] <cnd> and tries to follow touches and assign them to tracked slots
[21:42] <cnd> let's imagine that mtdev thinks there's a touch in the middle of the trackpad
[21:42] <cnd> if you then physically touch in the middle of the trackpad, it will think it's the same touch
[21:43] <cnd> but if you touch somewhere else, it will think it's a different touch
[21:43] <cnd> that would explain why sometimes it acts like there's one touch, and sometimes two
[21:44] <sforshee> I was trying to see if the right vs. left click correlated with where I clicked, but I didn't get a good feel for it before it wedged
[21:49] <cnd> sforshee, I wonder if you can reproduce by keeping one finger touching while you log out to restart the X server?
[21:50] <sforshee> cnd, just during the logout? or hold it down when logging in too?
[21:53] <cnd> just during the X server restart
[21:54] <cnd> once you hit the greeter you can release
[21:54] <cnd> then type your pw to log in
[21:54] <cnd> then test
[21:56] <sforshee> something doesn't like that very much :(
[21:56] <sforshee> the one time it worked it didn't reproduce the bug. but I got several hangs
[21:58] <cnd> hmm
[21:58] <cnd> what kinds of hangs?
[21:58] <sforshee> I can ssh in, so the system is still up, but the desktop is completely frozen
[22:00] <cnd> sforshee, keyboard input doesn't work?
[22:00] <cnd> because a stuck pointer would look like a hung system
[22:00] <sforshee> nope
[22:00] <sforshee> in fact this last time it hung before displaying the greeter
[22:01] <cnd> hmm
[22:01] <sforshee> can't switch to vt1 either
[22:01] <cnd> what about from your ssh session
[22:01] <cnd> sudo chvt 1
[22:01] <cnd> sudo stop lightdm
[22:01] <cnd> either of those work?
[22:02] <cnd> sudo killall -9 X
[22:02] <cnd> :)
[22:03] <sforshee> chvt 1 doesn't work, it seems to be stick in ioctl(3, VT_WAITACTIVE
[22:03] <sforshee> service lightdm stop works
[23:33] <RAOF> I love that the X server can disallow VT switching.  It makes everything so much more robust :/