Bug 106534

Have tested resultant packages with noted hardware and they work as expected.  Double-tap works and doesn't need triple-tap, or a conscious tap methodology, to compensate.

Perused code-base but only see:
 	if (device->model_flags &	    (EVDEV_MODEL_MS_NANO_TRANSCEIVER)) {
 		dispatch->debounce.state = DEBOUNCE_STATE_DISABLED;
 		return;
 	}

Guessing that a framework for problem devices is being hashed out. My user abilities are limited to Google and logical trouble-shooting.

Thanks! That patch catches all 0x404* devices from Logitech, including e.g. the MX Master (4041) which afaik doesn't suffer from this issue. So it'd be better to have the affected IDs listed explicitly but use a more generic model tag instead, LIBINPUT_MODEL_SHORT_DOUBLE_CLICK or something like that. That can also then be used for the MS nano devices. 

Can you update the patch for this please?

What level of complication are you looking for?  

This function will be overloaded in no time.  Three more entries and three more "or" | statements.  

Piece of cake to write a patch but the code that exists right now is a work-around and lacks the needed facility to create extensible user-friendly patches.  It's just a stop-gap.

It's a blurry rule at best: anything that looks device-specific should be so until we realise we have too many devices that suffer from the same issue. See e.g. the MODEL_CHROMEBOOK and SYNAPTICS_SERIAL_TOUCHPAD which apply to too many devices to be separate. And the advantage of having a more generic (descriptive) tag is that we can just update the hwdb to add new devices, if we add it one-by-one we also need to recompile libinput every time. Plus, it's easier to read for the next contributor and less chance of forgetting to update each of the 3 locations it needs to be put in.

Created attachment 139604 [details] [review]
Segmented Patch for source package in Cosmic 1.10.6

Going to write this detailed so other users can begin submitting their problem device patches.

How to tell if an input device matches?  Double-tap or click works but not as expected.  The second tap or click seems to be ignored and works if the user lengthens the time between the first and second tap/click.

lsusb
Bus 008 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver

dmesg |grep -i Logitech
input: Logitech K830 as /devices/pci0000:00/0000:00:10.1/usb8/8-2/8-2.2/8-2.2:1.2/0003:046D:C52B.0003/0003:046D:404C.0004/input/input3

cat /sys/class/input/input3/event3/device/modalias 
input:b0003v046Dp404Ce0111-e0,[...],sfw

Notice how the modalias numbers match the dmesg.  Our target will be:
libinput:mouse:input:b0003v046Dp404C*

Using Ubuntu 18.04 bionic, there's a K400 patch already in upstream 18.10 cosmic so add *only* its source repository:
echo "deb-src http://us.archive.ubuntu.com/ubuntu/ cosmic main universe multiverse" | sudo tee /etc/apt/sources.list.d/cosmic.list
sudo apt update
sudo apt build-dep libinput10
apt source libinput10
cd libinput-1.10.6

Determine which libinput components are installed:
apt policy libinput10 libinput-dev libinput-bin libinput-tools
libinput10:
  Installed: 1.10.4-1
  Candidate: 1.10.4-1
  Version table:
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
libinput-dev:
  Installed: 1.10.4-1
  Candidate: 1.10.4-1
  Version table:
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
libinput-bin:
  Installed: 1.10.4-1
  Candidate: 1.10.4-1
  Version table:
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
libinput-tools:
  Installed: (none)
  Candidate: 1.10.4-1
  Version table:
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

Search the contents of every file in the source directory for text "K400".  Should return these files and edits are shown:
libinput-1.10.6.orig/src/evdev-debounce.c
Original:
	if (device->model_flags &
	    (EVDEV_MODEL_MS_NANO_TRANSCEIVER|EVDEV_MODEL_LOGITECH_K400)) {
		dispatch->debounce.state = DEBOUNCE_STATE_DISABLED;
		return;
	}
Modified:
	if (device->model_flags &
	    (EVDEV_MODEL_MS_NANO_TRANSCEIVER|EVDEV_MODEL_LOGITECH_K400|EVDEV_MODEL_LOGITECH_K400r|EVDEV_MODEL_LOGITECH_K830|EVDEV_MODEL_LOGITECH_K400Plus)) {
		dispatch->debounce.state = DEBOUNCE_STATE_DISABLED;
		return;
	}

libinput-1.10.6.orig/src/evdev.c
Original:
		MODEL(LOGITECH_K400),
Modified:
		MODEL(LOGITECH_K400),
		MODEL(LOGITECH_K400r),
		MODEL(LOGITECH_K830),
		MODEL(LOGITECH_K400Plus),

libinput-1.10.6.orig/src/evdev.h
Original:
	EVDEV_MODEL_LOGITECH_K400 = (1 << 11),
	EVDEV_MODEL_TABLET_MODE_NO_SUSPEND = (1 << 30),
Modified:
	EVDEV_MODEL_LOGITECH_K400 = (1 << 11),
	EVDEV_MODEL_TABLET_MODE_NO_SUSPEND = (1 << 30),
	EVDEV_MODEL_LOGITECH_K400r = (1 << 31),
	EVDEV_MODEL_LOGITECH_K830 = (1 << 32),
	EVDEV_MODEL_LOGITECH_K400Plus = (1 << 33),

libinput-1.10.6.orig/udev/90-libinput-model-quirks.hwdb
Original:
# Logitech K400
libinput:mouse:input:b0003v046Dp4024*
 LIBINPUT_MODEL_LOGITECH_K400=1
Modified:
# Logitech K400
libinput:mouse:input:b0003v046Dp4024*
 LIBINPUT_MODEL_LOGITECH_K400=1

# Logitech K400r
libinput:mouse:input:b0003v046Dp404B*
 LIBINPUT_MODEL_LOGITECH_K400r=1
 
# Logitech K830
libinput:mouse:input:b0003v046Dp404C*
 LIBINPUT_MODEL_LOGITECH_K830=1

# Logitech K400Plus
libinput:mouse:input:b0003v046Dp404D*
 LIBINPUT_MODEL_LOGITECH_K400Plus=1

Commit changes to the local tree:
dpkg-source --commit
dpkg-source: info: local changes detected, the modified files are:
 libinput-1.10.6/src/evdev-debounce.c
 libinput-1.10.6/src/evdev.c
 libinput-1.10.6/src/evdev.h
 libinput-1.10.6/udev/90-libinput-model-quirks.hwdb
Enter the desired patch name: LOGICOMBO
Select (1) nano, CTRL+X, Y to save.  Created patch = debian/patches/LOGICOMBO, specified in file debian/patches/series

debuild -uc -us
cd ..
dpkg -i libinput10_1.10.6-1_amd64.deb libinput-bin_1.10.6-1_amd64.deb libinput-dev_1.10.6-1_amd64.deb

reboot


apt policy libinput10 libinput-dev libinput-bin libinput-tools
libinput10:
  Installed: 1.10.6-1
  Candidate: 1.10.6-1
  Version table:
 *** 1.10.6-1 100
        100 /var/lib/dpkg/status
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
libinput-dev:
  Installed: 1.10.6-1
  Candidate: 1.10.6-1
  Version table:
 *** 1.10.6-1 100
        100 /var/lib/dpkg/status
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
libinput-bin:
  Installed: 1.10.6-1
  Candidate: 1.10.6-1
  Version table:
 *** 1.10.6-1 100
        100 /var/lib/dpkg/status
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
libinput-tools:
  Installed: (none)
  Candidate: 1.10.4-1
  Version table:
     1.10.4-1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages

Notice that our packages are not associated with a bionic repository.  When done testing, revert to package management version by specifing version number:
sudo apt install libinput10=1.10.4-1 libinput-dev=1.10.4-1 libinput-bin=1.10.4-1

All edits were based on conjecture.  I'm not a programmer, affiliated with libinput development, nor do I really know anything about any of it.

New patch doesn't work anyway since too many values were packed in evdev.h and the compiler warns it can't left shift more than 32 widgets into enum evdev_device_model {. 

There you have it folks, current framework doesn't support more patches.  Changing severity as situation is impossible.

Oh, come off it. It's not impossible and took a total of 10 minutes to fix as I suggested in comment #2. I was hoping that you'd take the time to investigate so I didn't have to write the patches myself again but well, that remained a hope.

Note that this here is the upstream bugzilla, not ubuntu's launchpad so instructions to rebuild debian packages just add noise. And tbh, hardly anyone reads the libinput documentation so if you think anyone's going to read your instructions in a random bug report you're a lot more optimistic than I am.

Anyway, thanks for the model numbers, I've added them, the patch is on git master now.

commit 6dcdfdd513fd8158bc7bacbad8c5c8ba987565a0
Author: Peter Hutterer <>
Date:   Thu May 17 12:36:03 2018 +1000

     evdev: add three more Logitech K400-like devices to the debouncing quirk


PS: no-one looks at the severity, it's only abused anyway because everyone thinks their bug is the most important and severe one.

Created attachment 139612 [details] [review]
Corrected no-debounce for source package in Cosmic 1.10.6

Was dreaming about this issue last night, that's when you know good trouble-shooting is taking place.  

Existing patch in Cosmic must be wrong.  Addition of K400 patch uses same no-debounce code created for MS_NANO_TRANSCEIVER=1.  That code defines the debounce exception handler and isn't supposed to be extensible.  Removed all existing entries for K400 and localized changes to libinput-1.10.6/udev/90-libinput-model-quirks.hwdb.

Built my own sources clean:
apt --build source libinput10

Created /etc/udev/hwdb.d/99-no-debounce.hwdb:
# Logitech K400r
libinput:mouse:input:b0003v046Dp404B*
 LIBINPUT_MODEL_MS_NANO_TRANSCEIVER=1
 
# Logitech K830
libinput:mouse:input:b0003v046Dp404C*
 LIBINPUT_MODEL_MS_NANO_TRANSCEIVER=1

# Logitech K400Plus
libinput:mouse:input:b0003v046Dp404D*
 LIBINPUT_MODEL_MS_NANO_TRANSCEIVER=1

sudo cp 99-no-debounce.hwdb /etc/udev/hwdb.d/99-no-debounce.hwdb
sudo udevadm hwdb --update

The wording of the original patch could be a bit more generic to give a clue as to purpose, something like LIBINPUT_MODEL_GENERIC_NODEBOUNCE.  Regardless, those entries state that the LIBINPUT_MODEL_MS_NANO_TRANSCEIVER quirk will be applied to matching devices.

Users wanting to test no-debounce should get upstream packages with the code, create a 99-no-debounce.hwdb and, upon successful test, migrate changes to udev/90-libinput-model-quirks.hwdb.

Libinput 1.10.4, in Ubuntu Bionic, already has the necessary code.  Follow  the noted procedure to test.  Not really sure how to formally request inclusion of user tested hardware into 90-libinput-model-quirks.hwdb.

As an aside, most of the exception handlers have device specific descriptors for quirks, presumably because that was the first identified and fixed.  Hard to correlate what the quirks are for or how to use them without some formal documentation.

Just a user looking out for other users.