Description of problem:
The Synaptics driver loses the "button up" event often.
Version-Release number of selected component (if applicable):
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!
Scrollbar scrolls by itself.
No loss of "up" events.
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
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.
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]
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
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
No idea if this works with synaptics but it's useful for other devices.
This is still a problem with:
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]
Created attachment 315014 [details]
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.
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:
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
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.
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
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.
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.
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.