Bug 233717 - Synaptics loses button up event
Synaptics loses button up event
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-synaptics (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-23 19:24 EDT by Pete Zaitcev
Modified: 2008-10-15 22:12 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-08 15:16:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.conf (automacally generated) (803 bytes, text/plain)
2007-03-23 19:24 EDT, Pete Zaitcev
no flags Details
Xorg.0.log (53.93 KB, text/plain)
2008-01-08 23:45 EST, Pete Zaitcev
no flags Details
synclient -l (1.61 KB, text/plain)
2008-08-26 12:20 EDT, Pete Zaitcev
no flags Details
synclient -m20 (160.97 KB, text/plain)
2008-08-26 12:21 EDT, Pete Zaitcev
no flags Details
Xorg.0.log with extra printout (144.19 KB, application/octet-stream)
2008-08-27 18:45 EDT, Pete Zaitcev
no flags Details
Xorg.0.log with -13 (202.13 KB, text/plain)
2008-08-28 14:40 EDT, Pete Zaitcev
no flags Details
Patch 1/2 synaptics-0.14.6-midbutton-timeout.patch (2.59 KB, patch)
2008-09-03 08:31 EDT, Pete Zaitcev
no flags Details | Diff
Patch 2/2 synaptics-0.14.6-midbutton-reset.patch (611 bytes, patch)
2008-09-03 08:32 EDT, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Pete Zaitcev 2007-03-23 19:24:45 EDT
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.
Comment 1 Pete Zaitcev 2007-03-23 19:24:45 EDT
Created attachment 150807 [details]
xorg.conf (automacally generated)
Comment 2 Matěj Cepl 2007-12-07 08:48:55 EST
Can we get your /var/log/Xorg.0.log as well, please?
Comment 3 Pete Zaitcev 2007-12-07 19:00:03 EST
Seems like it's gone in FC8+ Rawhide.

xorg-x11-drivers-7.2-9.fc8
gtk2-2.12.1-2.fc8
Comment 4 Pete Zaitcev 2008-01-08 23:45:14 EST
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-08 23:45:53 EST
Created attachment 291113 [details]
Xorg.0.log
Comment 6 Bug Zapper 2008-05-13 22:41:33 EDT
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
Comment 7 Peter Hutterer 2008-07-18 00:42:12 EDT
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.

Comment 8 Pete Zaitcev 2008-08-23 21:30:21 EDT
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).
Comment 9 Peter Hutterer 2008-08-26 02:29:05 EDT
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 12:20:21 EDT
Created attachment 315013 [details]
synclient -l
Comment 11 Pete Zaitcev 2008-08-26 12:21:13 EDT
Created attachment 315014 [details]
synclient -m20
Comment 12 Pete Zaitcev 2008-08-26 12:26:31 EDT
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 02:56:26 EDT
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/
Comment 14 Pete Zaitcev 2008-08-27 18:45:03 EDT
Created attachment 315158 [details]
Xorg.0.log with extra printout
Comment 15 Pete Zaitcev 2008-08-27 18:49:46 EDT
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 04:49:49 EDT
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/
Comment 17 Pete Zaitcev 2008-08-28 14:22:32 EDT
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.
Comment 18 Pete Zaitcev 2008-08-28 14:40:40 EDT
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 19:32:47 EDT
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/
Comment 20 Matěj Cepl 2008-08-29 19:42:43 EDT
Pete, does that build from comment 19 help?
Comment 21 Pete Zaitcev 2008-09-01 19:33:25 EDT
synaptics-0.14.6-14.fc10 appears to work (tested it for half an hour or so).
Comment 22 Pete Zaitcev 2008-09-02 19:19:59 EDT
As far as I'm concerned, this bug is good to close as soon as -14 hits
Rawhide.
Comment 23 Pete Zaitcev 2008-09-03 08:28:27 EDT
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 08:31:19 EDT
Created attachment 315636 [details]
Patch 1/2 synaptics-0.14.6-midbutton-timeout.patch
Comment 25 Pete Zaitcev 2008-09-03 08:32:05 EDT
Created attachment 315637 [details]
Patch 2/2 synaptics-0.14.6-midbutton-reset.patch
Comment 26 Peter Hutterer 2008-09-03 09:43:35 EDT
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 15:16:31 EDT
xorg-x11-drv-synaptics-0.15.0-4.fc10.x86_64 works, closing the bug.
Comment 28 Fedora Update System 2008-09-09 10:43:33 EDT
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
Comment 29 Pete Zaitcev 2008-09-13 22:05:14 EDT
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 02:52:12 EDT
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-22 20:25:47 EDT
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
Comment 32 Fedora Update System 2008-10-15 22:12:56 EDT
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.