Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 233717 - Synaptics loses button up event
Summary: Synaptics loses button up event
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-synaptics
Version: rawhide
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-23 23:24 UTC by Pete Zaitcev
Modified: 2018-04-11 11:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-09-08 19:16:31 UTC

Attachments (Terms of Use)
xorg.conf (automacally generated) (deleted)
2007-03-23 23:24 UTC, Pete Zaitcev
no flags Details
Xorg.0.log (deleted)
2008-01-09 04:45 UTC, Pete Zaitcev
no flags Details
synclient -l (deleted)
2008-08-26 16:20 UTC, Pete Zaitcev
no flags Details
synclient -m20 (deleted)
2008-08-26 16:21 UTC, Pete Zaitcev
no flags Details
Xorg.0.log with extra printout (deleted)
2008-08-27 22:45 UTC, Pete Zaitcev
no flags Details
Xorg.0.log with -13 (deleted)
2008-08-28 18:40 UTC, Pete Zaitcev
no flags Details
Patch 1/2 synaptics-0.14.6-midbutton-timeout.patch (deleted)
2008-09-03 12:31 UTC, Pete Zaitcev
no flags Details | Diff
Patch 2/2 synaptics-0.14.6-midbutton-reset.patch (deleted)
2008-09-03 12:32 UTC, Pete Zaitcev
no flags Details | Diff

Description Pete Zaitcev 2007-03-23 23:24:45 UTC
Description of problem:

The Synaptics driver loses the "button up" event often.

Version-Release number of selected component (if applicable):


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.

Comment 1 Pete Zaitcev 2007-03-23 23:24:45 UTC
Created attachment 150807 [details]
xorg.conf (automacally generated)

Comment 2 Matěj Cepl 2007-12-07 13:48:55 UTC
Can we get your /var/log/Xorg.0.log as well, please?

Comment 3 Pete Zaitcev 2007-12-08 00:00:03 UTC
Seems like it's gone in FC8+ Rawhide.


Comment 4 Pete Zaitcev 2008-01-09 04:45:14 UTC
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.

Comment 5 Pete Zaitcev 2008-01-09 04:45:53 UTC
Created attachment 291113 [details]

Comment 6 Bug Zapper 2008-05-14 02:41:33 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 7 Peter Hutterer 2008-07-18 04:42:12 UTC
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.

Comment 8 Pete Zaitcev 2008-08-24 01:30:21 UTC
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).

Comment 9 Peter Hutterer 2008-08-26 06:29:05 UTC
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.

Comment 10 Pete Zaitcev 2008-08-26 16:20:21 UTC
Created attachment 315013 [details]
synclient -l

Comment 11 Pete Zaitcev 2008-08-26 16:21:13 UTC
Created attachment 315014 [details]
synclient -m20

Comment 12 Pete Zaitcev 2008-08-26 16:26:31 UTC
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.

Comment 13 Peter Hutterer 2008-08-27 06:56:26 UTC
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

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.

Comment 14 Pete Zaitcev 2008-08-27 22:45:03 UTC
Created attachment 315158 [details]
Xorg.0.log with extra printout

Comment 15 Pete Zaitcev 2008-08-27 22:49:46 UTC
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).

Comment 16 Peter Hutterer 2008-08-28 08:49:49 UTC
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:

Comment 17 Pete Zaitcev 2008-08-28 18:22:32 UTC
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

Comment 18 Pete Zaitcev 2008-08-28 18:40:40 UTC
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.

Comment 19 Peter Hutterer 2008-08-28 23:32:47 UTC
gah. of course, I forgot to reset the state after posting the event, causing the clicks to be reposted again and again.

Comment 20 Matěj Cepl 2008-08-29 23:42:43 UTC
Pete, does that build from comment 19 help?

Comment 21 Pete Zaitcev 2008-09-01 23:33:25 UTC
synaptics-0.14.6-14.fc10 appears to work (tested it for half an hour or so).

Comment 22 Pete Zaitcev 2008-09-02 23:19:59 UTC
As far as I'm concerned, this bug is good to close as soon as -14 hits

Comment 23 Pete Zaitcev 2008-09-03 12:28:27 UTC
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?

Comment 24 Pete Zaitcev 2008-09-03 12:31:19 UTC
Created attachment 315636 [details]
Patch 1/2 synaptics-0.14.6-midbutton-timeout.patch

Comment 25 Pete Zaitcev 2008-09-03 12:32:05 UTC
Created attachment 315637 [details]
Patch 2/2 synaptics-0.14.6-midbutton-reset.patch

Comment 26 Peter Hutterer 2008-09-03 13:43:35 UTC
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.

Comment 27 Pete Zaitcev 2008-09-08 19:16:31 UTC
xorg-x11-drv-synaptics-0.15.0-4.fc10.x86_64 works, closing the bug.

Comment 28 Fedora Update System 2008-09-09 14:43:33 UTC
xorg-x11-drv-synaptics-0.15.1-1.fc9 has been submitted as an update for Fedora 9.

Comment 29 Pete Zaitcev 2008-09-14 02:05:14 UTC
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.

Comment 30 Peter Hutterer 2008-09-15 06:52:12 UTC
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).

Comment 31 Fedora Update System 2008-09-23 00:25:47 UTC
xorg-x11-drv-synaptics-0.15.1-2.fc9 has been submitted as an update for Fedora 9.

Comment 32 Fedora Update System 2008-10-16 02:12:56 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.