Bug 103054

Summary:	Debouncing active but no effect
Product:	Wayland	Reporter:	mrblooter
Component:	libinput	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium	CC:	peter.hutterer
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Xorg log evemu-record log Longer evemu-record log

Description mrblooter 2017-10-01 14:16:28 UTC

Created attachment 134596 [details]
Xorg log

I have a mouse which double clicks often and I decided to give the debouncing feature a try. I built libinput from the master branch and installed it.

It detects the doubleclicks and turns itself on as seen from this line in the log:

>[   168.818] (II) event3  - (II) Logitech USB Optical Mouse: (II) Enabling button debouncing, see https://wayland.freedesktop.org/libinput/doc/latest/button_debouncing.html for details

Despite that, the mouse still double clicks sometimes instead of performing just a single click. I understand that getting a new mouse is easier, but I thought I could help to improve this. Is it possible that the double-clicking issue is broken in a way where it's impossible to fix it with software?

Either way, if you need more information I can provide it. I attached the Xorg log.

Libinput version: latest build from master
Xorg version: 1.19.3
xf86-input-libinput version: 0.26

Comment 1 Peter Hutterer 2017-10-02 10:35:06 UTC

Please attach an evemu-record that captures such a button bounce. Could be a timeout issue. Thanks.

Comment 2 mrblooter 2017-10-03 15:55:02 UTC

Created attachment 134637 [details]
evemu-record log

Here is the evemu-record log.
One of those double clicks happened at the end, around line 1160-1170.

Comment 3 Peter Hutterer 2017-10-03 22:41:35 UTC

I suspect it's this seqeuence here:

  E: 9.895899 0004 0004 589825    # EV_MSC / MSC_SCAN             589825
  E: 9.895899 0001 0110 0001      # EV_KEY / BTN_LEFT             1
  E: 9.895899 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +120ms
  E: 9.927929 0004 0004 589825    # EV_MSC / MSC_SCAN             589825
  E: 9.927929 0001 0110 0000      # EV_KEY / BTN_LEFT             0
  E: 9.927929 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +32ms
  E: 9.943937 0004 0004 589825    # EV_MSC / MSC_SCAN             589825
  E: 9.943937 0001 0110 0001      # EV_KEY / BTN_LEFT             1
  E: 9.943937 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +16ms
  E: 9.991900 0004 0004 589825    # EV_MSC / MSC_SCAN             589825
  E: 9.991900 0001 0110 0000      # EV_KEY / BTN_LEFT             0
  E: 9.991900 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +48ms

Debounce detection is based on timeouts, but here the time between the fake
release and the next press is 16ms vs the 12 libinput currently uses. If you
can, grab libinput from git and modify DEBOUNCE_TIME to 17ms. See if that
helps consistently.

Comment 4 mrblooter 2017-10-04 15:37:18 UTC

Created attachment 134663 [details]
Longer evemu-record log

I have increased the time to 16ms, but I still experienced double-clicks.

Then I recorded the events for a longer time and checked again. I'm not sure if I'm looking at the time for the right event, but I noticed on some double-clicks it goes up to 64ms (line 3048 in the attachment). Am I looking at the correct event?

After that I increased it again from 16ms to 64ms and the double-clicks seemed to have stopped. However, I experienced another issue, where it would start dragging the directory. I think that 64ms is too high and interferes with desired events?
I assume some mice with inconsistent and too high delays between false clicks can't be fixed this way?

Either way, thank you for the help. I guess this is RESOLVED now and can be closed.

Comment 5 Peter Hutterer 2017-10-04 21:51:51 UTC

yeah, basically that's the problem. Timeouts are the only way we can detect these false clicks but if the timeouts go too close or above what you would otherwise trigger by manually clicking (which can be in the ~20ms range) then you start getting stuck buttons.

If you get 64ms for those fake clicks, there isn't really anything we can do and you're really better off getting a new mouse. Anything else would require putting special behaviours in that you then have to train yourself to stick to. Not really worth the effort because it's still likely going to be unreliable.

So sorry, I'm going to have to close this bug.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.