1

I'm using libinput (on nixos 20.03/KDE plasma 5.17 with default configuration), and I've a quite annoying behaviour: when I untouch my touchpad during a selection or a drag and drop, the click is not release directly, and I need to wait ~0.3 seconds to see the click released.

While it may seem minor, it's very annoying, because if I click again, it continues the old selection/drag and drop like if I never released my button. Therefore, if I select something, and want to click on a button right after to perform an action for example, I will in fact change my selection.

Any idea how to change that behaviour?

Thanks!

EDIT: To answer to Hi-Angel, I do have these messages without delay:

 event18  POINTER_MOTION   +12.343s       0.88/  0.00 ( +1.00/ +0.00)
 event18  POINTER_MOTION   +12.352s       0.88/  0.00 ( +1.00/ +0.00)
event18 - button state: touch 0 from BUTTON_STATE_AREA    event BUTTON_EVENT_UP          to BUTTON_STATE_NONE   
event18 - button state: touch 0 from BUTTON_STATE_NONE    event BUTTON_EVENT_IN_AREA     to BUTTON_STATE_AREA
 event18  POINTER_MOTION   +12.524s       0.00/  0.88 ( +0.00/ +1.00)
 event18  POINTER_MOTION   +12.541s       0.00/  0.86 ( +0.00/ +1.00)

and I'm using libinput 1.15.0.

3
  • 1
    Possibly this may be caused by libinput_device_config_tap_set_drag_lock_enabled() feature, which sets delay before releasing. libinput settings have different implementations in Wayland WMs / X11.
    – chzzh
    Jul 9 '20 at 8:36
  • It may be a problem in libinput or elsewhere in the stack. Please run libinput debug-events --verbose, start selection with touchpad, and then release it while looking at the output. You should see something like button state: touch 0 from BUTTON_STATE_AREA event BUTTON_EVENT_UP to BUTTON_STATE_NONE or maybe BTN_LEFT (272) released appear. If there's the delay you mention before it appears, then it's likely the libinput problem. While on it: what libinput version do you have?
    – Hi-Angel
    Jul 9 '20 at 13:05
  • Thanks, problem solved, it was indeed due to drag lock as seen by @chzzh. Thanks a lot, feel free to write or copy paste my answer if you want me to accept it.
    – tobiasBora
    Jul 10 '20 at 10:13
0

As pointed out by chzzh in comments, it is actually a feature, not a bug. I don't like that feature, which is enabled by default on NixOs, so I disabled it.

To temporary disable it, first get the id of the touch pad by looking at the list here:

$ xinput list

then run (after replacing ID_OF_TOUCHPAD with the corresponding id):

xinput --set-prop ID_OF_TOUCHPAD "libinput Tapping Drag Lock Enabled" 0

(you can see the full list of options for a particular device with xinput list-props ID_OF_TOUCHPAD)

On Nixos, to disable it permanently, you just need to put in your configuration.nix the following:

services.xserver.libinput.tappingDragLock = false;

Note that it seems that you need to reboot to see the changes applied.

On other systems, I think it's disabled by default, but you may want to change X11 options as here.

1
  • Also try setting "Evdev Debounce Delay" to 0. This worked for me, as the other one was already 0.
    – LatinSuD
    Oct 11 '20 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.