Description of problem: The Synaptics driver loses the "button up" event often. Version-Release number of selected component (if applicable): xorg-x11-drivers-7.2-4.fc7 How reproducible: Happens almost constantly, but reproducing on demand can be tricky. See Additional Info for discusson. Steps to Reproduce: 0. Have a laptop with Synaptics (Dell 1501 in this case). 1. Configure Synaptics in xorg.conf (see example below). 2. Find a scrollbar and a long text. Firefox works the best, but actually it's not an application dependent. 3. Start clicking. Just be patient... Vary the down duration. I'm not sure if tapping would work, please use a real button. Be sure not to keep a finger on the pad (see below)! 4. The symptom is, scrollbar starts scrolling on its own with button released. That's the bug! Actual results: Scrollbar scrolls by itself. Expected results: No loss of "up" events. Additional info: Once the condition has happened, any kind of motion or touch to the touchpad will restore it. I looked at the event stream with strace, but the synaptics uses /dev/input/eventN (even though /dev/input/mice is specified), so the format is a bit complicated. I can't tell if the up event is there or not. Why I think this is not just a bad touchpad? Actually, I saw it on two laptops. But mostly because replacing "synaptics" with "mouse" fixes the issue, and both the mousedev consumes exactly the same event stream as X takes from eventN. If the in-kernel synaptics were losing the up event, the mouse module would show it too. Filing this against synaptics because there's no suitable X11 driver component. But notice that utilities are not involved.
Created attachment 150807 [details] xorg.conf (automacally generated)
Can we get your /var/log/Xorg.0.log as well, please?
Seems like it's gone in FC8+ Rawhide. xorg-x11-drivers-7.2-9.fc8 gtk2-2.12.1-2.fc8
It's reoccured. Mind though, this system wasn't updates since the X breakage due to the libpciaccess. Let me know if I should update any components. I'm going to attach the Xorg.0.log per comment #2.
Created attachment 291113 [details] Xorg.0.log
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Pete, what's the status of this? Which version are you running now? The last log indicated F8/x server 1.3. Is this still correct? (In reply to comment #0) > I looked at the event stream with strace, but the synaptics uses > /dev/input/eventN (even though /dev/input/mice is specified), so > the format is a bit complicated. I can't tell if the up event is > there or not. evtest is useful for debugging, I put up a copy on http://people.freedesktop.org/~whot/evtest.c No idea if this works with synaptics but it's useful for other devices.
This is still a problem with: synaptics-0.14.6-10.fc10.x86_64 xorg-x11-server-Xorg-1.4.99.906-5.fc10.x86_64 I have evtest, because I have to deal with kernel input subsystem in RHEL. But it won't show anything while X is running. It would be useful if the kernel module was broken, but in this case I think it's something inside X (because "mouse" worked).
Can you configure shm for synaptics and run synclient please? I spent some time clicking now but I don't see this issue. Option "SHMConfig" "true" in the InputDevice section, and then synclient -l (for the initial settings) and then synclient -m20. If it's the hardware (or elsewhere in the driver), the last line when it hangs should have "1" (one) in the column "l" (lowercase L). If it's in the server (or some of the button emulation code), then this column should be 0.
Created attachment 315013 [details] synclient -l
Created attachment 315014 [details] synclient -m20
Here's what happened. I noticed that synclient records everything and so the desired event will be buried in motions. So, I figured I'd use the keyboard to navigate to terminal once it happened and interrupt synclient. Well... once it happened, the keyboard navigation fails because the button is considered "stuck". So I hit Alt-TAB a few times with no success, thinking. This is why the gap between 196.474 and 234.537. Eventually I remembered that the "stuck" button comes unstuck no matter what event is delivered (e.g. motion or other), and hit the right button at 234. That unfroze the X and let me Alt-TAB into terminal and kill synclient.
196.398 1 5855 0 0 0 1 0 0 0 0 00000000 0 0 0 0 0 196.474 1 5855 0 0 0 0 0 0 0 0 00000000 0 0 0 0 0 234.537 1 5855 0 0 0 0 1 0 0 0 00000000 0 0 0 0 0 234.677 1 5855 0 0 0 0 0 0 0 0 00000000 0 0 0 0 0 So the button event is seen by the hardware (and thus the driver). But I can't see where it might get lost. I'd appreciate it if you could try the package available at http://whot.fedorapeople.org/synaptics/ It simply prints to the log when a button event is posted. Not much, but it may help. The patch file is only modification, compiled rpms are available if you don't want to patch the driver yourself. http://koji.fedoraproject.org/scratch/whot/task_788252/
Created attachment 315158 [details] Xorg.0.log with extra printout
I think we can see the problem here (end of the attached log): (EE) Mouse0: 119741513 posting bt event 1 (1) (EE) Mouse0: 119741834 posting bt event 1 (0) (EE) Mouse0: 119741842 posting bt event 1 (1) (EE) Mouse0: 119746514 posting bt event 1 (0) (EE) Mouse0: 119746514 posting bt event 3 (4) (EE) Mouse0: 119750024 posting bt event 3 (0) The gap between 119741842 and 119746514 is big, that's when I saw the scrollbar running amok. Then I only clicked the right button, but something generated an "up" even for the stuck button (which actually was released somewhere around 119742150, if we assume that it takes me about 300ms to click).
Thanks, I think I got it. Here's what happens: On a left/right button press, middle button emulation springs into action and changes the reported hw state. It then returns a delay that is supposed to set a timer. No button event is posted to the server, the timer ensures that it'll be posted later. If however - in the same cycle - the button up is reported, but with a hardware time > middle emulation timeout, the middle button emulation is canceled. The hw state is reset to button down, and processing continues, reporting the button down event. Since this is in the same cycle, the new delay overrides the previous one and the timer is never set. Well, it is but to now + 1000000000 ms. If you can wait that long, it should stop scrolling then :) This explains why firefox is so reliable in reproducing this - rendering takes time and may trigger this issue. Test packages are available at: http://whot.fedorapeople.org/synaptics/ http://koji.fedoraproject.org/scratch/whot/task_789892/
I installed synaptics-0.14.6-13.fc10.x86_64. It fixes the original issue, but I see some very weird effect... Selection flashes like crazy and changes shape as I move the cursor around. It looks as if motion with no buttons pressed reports stray button up and down. I have not identified the sequence of events that triggers it yet. It seems like it's essential to switch between applications for it to happen, but I don't know anything else.
Created attachment 315278 [details] Xorg.0.log with -13 This is a log captured when this happens, but I don't see a distinctive start to it. You can only guess when it begins by looking at timestamps.
gah. of course, I forgot to reset the state after posting the event, causing the clicks to be reposted again and again. http://koji.fedoraproject.org/scratch/whot/task_791900/
Pete, does that build from comment 19 help?
synaptics-0.14.6-14.fc10 appears to work (tested it for half an hour or so).
As far as I'm concerned, this bug is good to close as soon as -14 hits Rawhide.
Oh this is just hilarious... Since Rawhide came back after the intrusion, I ran "yum update", and it deleted Peter's synaptics package. Now the problem is back. Evidently xorg-x11-drv-synaptics-0.15.0-3.fc10 has exactly the same bug that was fixed just now. The xorg-x11-drv-synaptics and synaptics conflict. Which one do we have want to ship? Should I change the bug's component and reassign it?
Created attachment 315636 [details] Patch 1/2 synaptics-0.14.6-midbutton-timeout.patch
Created attachment 315637 [details] Patch 2/2 synaptics-0.14.6-midbutton-reset.patch
I pushed xorg-x11-drv-synaptics 0.15.0-4 yesterday which includes the patch, just give it time to trickle. xorg-x11-drv-synaptics replaces synaptics.
xorg-x11-drv-synaptics-0.15.0-4.fc10.x86_64 works, closing the bug.
xorg-x11-drv-synaptics-0.15.1-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-0.15.1-1.fc9
BTW, one funny thing I see with 0.15.0-4.fc10 is how sometimes it still reports extra clicks, but _very_ infrequently now. The usual symptom is, I try to drag a window and it suddenly maximizes because a double-click is produced instead of single. No pad taps are used, only physical buttons. Just FYI.
does this also happen if with TapButton1 = 0? It could be that you're underrunning the pressure threshold while dragging, causing a new click event to be sent when you're hitting the threshold again (this is mostly a stab in dark though).
xorg-x11-drv-synaptics-0.15.1-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xorg-x11-drv-synaptics-0.15.1-2.fc9
xorg-x11-drv-synaptics-0.15.1-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.