Dear all, the mouse "iONE Lynx-R17Nano" of my new wireless keyboard+mouse combo incorrectly sends BTN_FORWARD after sending BTN_LEFT when performing a left click. Here the corresponding output from libinput-debug-events: -event6 POINTER_BUTTON +4.73s BTN_LEFT (272) pressed, seat count: 1 event6 POINTER_BUTTON +4.73s BTN_FORWARD (277) pressed, seat count: 1 event6 POINTER_BUTTON +4.81s BTN_LEFT (272) released, seat count: 0 event6 POINTER_BUTTON +4.81s BTN_FORWARD (277) released, seat count: 0 This confuses gnome-shell and this mouse is useless for left-clicks. Disabling BTN_FORWARD via xorg.conf, everthing is fine. But sadly, I couldn't find a way to do that for wayland. So I'm looking for a way not to generate the event at all. These are the devices in question: Device: Cypress Semiconductor CY4672 PRoC LP RDK Bridge Kernel: /dev/input/event4 Group: 4 Seat: seat0, default Capabilities: keyboard Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: n/a Nat.scrolling: n/a Middle emulation: n/a Calibration: n/a Scroll methods: none Click methods: none Disable-w-typing: n/a Accel profiles: n/a Rotation: n/a Device: Cypress Semiconductor CY4672 PRoC LP RDK Bridge Kernel: /dev/input/event6 Group: 4 Seat: seat0, default Capabilities: keyboard pointer Tap-to-click: n/a Tap-and-drag: n/a Tap drag lock: n/a Left-handed: disabled Nat.scrolling: disabled Middle emulation: disabled Calibration: n/a Scroll methods: button Click methods: none Disable-w-typing: n/a Accel profiles: flat *adaptive Rotation: n/a For the records, I'm using ArchLinux, which currently has libinput-1.8.3. Any idea where to start digging? Kind regards!
Please attach the evemu-describe for this device, thanks. Benjamin, something we can add a quirk to in the kernel?
This looks pretty messed up at the hardware level :/ For confirmation, could you also attach the output of your dmesg since the boot (or plug in of the device), and also the hid-recorder traces of the left button click (project hid-replay: http://bentiss.github.io/hid-replay-docs/)
Created attachment 134833 [details] Output of evemu-describe
Created attachment 134834 [details] Output of hid-recorder, with --debugfs
Created attachment 134835 [details] Output of hid-recorder, without --debugfs
This is the relevant part of dmesg after plugging in the usb dongle: [ 122.856652] usb 1-1.1: new low-speed USB device number 5 using xhci_hcd [ 122.960310] input: Cypress Semiconductor CY4672 PRoC LP RDK Bridge as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.0/0003:04B4:06B0.0005/input/input16 [ 123.018128] hid-generic 0003:04B4:06B0.0005: input,hidraw0: USB HID v1.11 Keyboard [Cypress Semiconductor CY4672 PRoC LP RDK Bridge] on usb-0000:00:14.0-1.1/input0 [ 123.027309] input: Cypress Semiconductor CY4672 PRoC LP RDK Bridge as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1/1-1.1:1.1/0003:04B4:06B0.0006/input/input17 [ 123.084650] hid-generic 0003:04B4:06B0.0006: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Cypress Semiconductor CY4672 PRoC LP RDK Bridge] on usb-0000:00:14.0-1.1/input1 Please find the output of evemu-describe and hid-recorder attached. For the latter, I moved the mouse a little left, then right and then clicked the left button. What puzzels me is, that the mouse behaves properly on Windows 10 - even without installing a special driver. Could they include a quirk for the device? Or use some different mode?
Just FYI, you need this patch I sent a while ago as an RFC: https://patchwork.kernel.org/patch/9795625/ Basically, your mouse decides to send the same event through two fields in the HID report, and the HID core subsystem tries to be smarter and assign different values to the second ones it finds. I'll need to send this as a proper patch and get it accepted I think. Assigning to self, but don't be surprise if we close this as NOTOURBUG, I'll try to keep track of it still.
Created attachment 135159 [details] libinput debug-events with patch applied Benjamin, thanks for pushing this forward! I just tried your elder patch, however, it seems GTK+/GNOME is still confused about additional events, c.f. the output libinput debug-events. Please note, I built 4.13.10 with your changes. The patch mostly applied. The only exception was the line with HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE of hid.h, which I adapted to 4.13. Hopefully without any mistake.
I'll need another evemu-describe with the kernel patch applied please. Evdev code 271 (0x10f) was listed in the original describe so it looks like the patch had some effect here and instead of re-using BTN_FORWARD it now sends it through that bit. But the basic problem remains in that the device still sends a garbage event on this bit which we have to filter somewhere (preferably in the kernel :)
Created attachment 135175 [details] Output of evemu-describe with patch applied
Created attachment 135176 [details] Output of evemu-record with patch applied After discovering evemu-record, I thought a recording might be useful, too. Here is the order of mouse key presses I did: * left click * right click * left click * left double click Please let me know if I can do anything else :)
fwiw, evemu-record includes the evemu-describe output at the top, you don't need to attach the latter as separate file. diff between the evemu describes before/after: the device with the patched kernel does *NOT* have BTN_FORWARD, BTN_BACK and REL_DIAL which were previously present. The event comes through at 271 so it'd be easy enough to mask that in libinput.
Created attachment 136242 [details] [review] 0001-Add-a-model-quirk-for-the-iOne-Lynx-R71-Nano.patch Untested, please make sure it works. Note that this requires the kernel patch benjamin provided.
untested for 3+ weeks, closing
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.