Bug 25020 - ButtonRelease events are delayed
ButtonRelease events are delayed
Status: RESOLVED NOTOURBUG
Product: xorg
Classification: Unclassified
Component: Input/synaptics
unspecified
x86 (IA32) Linux (All)
: medium normal
Assigned To: Peter Hutterer
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-10 09:45 UTC by Glen Ditchfield
Modified: 2009-12-16 22:49 UTC (History)
1 user (show)

See Also:


Attachments
Xorg log (126.91 KB, text/x-log)
2009-11-10 09:45 UTC, Glen Ditchfield
no flags Details
/proc/bus/input/devices (1.93 KB, text/plain)
2009-11-10 09:51 UTC, Glen Ditchfield
no flags Details
Xorg log with evdev 2.3.0 (79.01 KB, text/plain)
2009-12-15 22:59 UTC, seph
no flags Details
Xorg log with mouse_drv.so (75.92 KB, text/plain)
2009-12-15 23:00 UTC, seph
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Glen Ditchfield 2009-11-10 09:45:57 UTC
Created attachment 31095 [details]
Xorg log

I have a Dell D600 laptop running Ubuntu 9.10 "Karmic Koala".  Sometimes when I click button 1, the button-down event is detected immediately, but the button-up event is not detected immediately.  If I clicked a GUI button, the GUI button remains in the depressed state.  If I clicked a hyperlink in the web page, the browser does not follow the link.  When I touch the trackpad to move the cursor, the GUI button pops up or the web browser jumps to the new page; it's as if the ButtonRelease event was held in a queue.

Here is xev output from a series of button-1 clicks.  I clicked button 1 until I saw a ButtonPress that was not followed by a ButtonRelease, then I waited several seconds, then I touched (but did not release) the trackpad; that's when the final ButtonRelease appeared.  (Note the time gap.)  Then I typed Alt-F4

ButtonPress event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84326059, (79,126), root:(1247,994),
    state 0x0, button 1, same_screen YES

ButtonRelease event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84326095, (79,126), root:(1247,994),
    state 0x100, button 1, same_screen YES

ButtonPress event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84330824, (79,126), root:(1247,994),
    state 0x0, button 1, same_screen YES

ButtonRelease event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84330906, (79,126), root:(1247,994),
    state 0x100, button 1, same_screen YES

ButtonPress event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84332285, (79,126), root:(1247,994),
    state 0x0, button 1, same_screen YES

ButtonRelease event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84349741, (79,126), root:(1247,994),
    state 0x100, button 1, same_screen YES

KeyPress event, serial 31, synthetic NO, window 0x3400001,
    root 0x73, subw 0x0, time 84365663, (79,126), root:(1247,994),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

I estimate that I see this happen about 1 click in 4 for button 1, and less often for button 2.  I've never noticed it when I tap the touchpad.

I see this behavior when running the Ubuntu 9.10 Live/Install image and with a  clean 9.10 installation.  I did not see this with Hardy Heron (X 1.4.0.90).
Comment 1 Glen Ditchfield 2009-11-10 09:51:10 UTC
Created attachment 31096 [details]
/proc/bus/input/devices

Note: I have no Xorg.conf file.
Comment 2 Peter Hutterer 2009-11-10 14:04:42 UTC
already fixed in evdev 2.3.0, see commit 36064dca9097df896b4b1b49c9c68775f1728846
Comment 3 seph 2009-12-15 22:58:38 UTC
I'm a different user, seeing the same problem. Upgrading to evdev 2.3.0, as supplied by https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates did not fix this problem.

I've been testing with xev, and see the originally described behavior both with evdev and with the traditional mouse_drv.so. I've attached Xorg.0.log files for both.
Comment 4 seph 2009-12-15 22:59:35 UTC
Created attachment 32102 [details]
Xorg log with evdev 2.3.0
Comment 5 seph 2009-12-15 23:00:18 UTC
Created attachment 32103 [details]
Xorg log with mouse_drv.so
Comment 6 Peter Hutterer 2009-12-15 23:07:17 UTC
which device does this happen with? the touchpad or a mouse device?
Comment 7 seph 2009-12-15 23:15:22 UTC
> which device does this happen with? the touchpad or a mouse device?

As the original poster, I have a dell d600. I see this problem with the internal touchpad/stick DualPoint device. An external usb mouse seems fine.

And as a footnote, the correct URL for the ubuntu package source is:
https://edge.launchpad.net/~xorg-edgers/+archive/ppa
Comment 8 Peter Hutterer 2009-12-16 14:27:24 UTC
judging by the log, there's a DualPoint Stick and an AlpsPS/2 ALPS DualPoint TouchPad device. In the first log, the stick is evdev, the alps pad is synaptics. Which of the two does the problem occur with? Both?

In the second log, both devices are driven through /dev/input/mice. Since you say the problem occurs with both, this indicates either a server bug or weird hardware.

Please get evtest (http://people.freedesktop.org/~whot/evtest/) and run it against the device that shows this problem. Then reproduce the problem and attach the evtest output here (please try to keep the output to a minimum). If you can, please also run evtest-capture so I can try to reproduce with a software device if needed.
Comment 9 seph 2009-12-16 22:16:10 UTC
> judging by the log, there's a DualPoint Stick and an AlpsPS/2 ALPS DualPoint
> TouchPad device. In the first log, the stick is evdev, the alps pad is
> synaptics. Which of the two does the problem occur with? Both?

Both. But I'm increasing convinced this is not X related, and is a problem in the kernel driver for the Alps stuff. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/296610?comments=all seems to be the best exploration of this that I've seen. I haven't tested that kernel patch yet, but if I load the psmouse kernel module using imps and not whatever it autodetects at, my problems all go away. 

> Please get evtest (http://people.freedesktop.org/~whot/evtest/) and run it
> against the device that shows this problem.

Do you still want this?

seph
Comment 10 Peter Hutterer 2009-12-16 22:49:56 UTC
I guess this qualifies as NOTOURBUG then (and likely for the original reporter). if the problem comes back please reopen the bug again. Don't worry about the evtest outputs for now. thanks for digging into this.