Bug 200847

Summary: mouse pointer does not move when using USB mouse 214e:0004
Product: Drivers Reporter: Wael Nasreddine (wael.nasreddine)
Component: Input DevicesAssignee: drivers_input-devices
Status: NEW ---    
Severity: normal CC: benjamin.tissoires, dmitry.torokhov, javier.tia+bugzilla.kernel, lb.kernel, ranisalt
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.18.2 Tree: Mainline
Regression: Yes
Attachments: lsusb -vvv of 214e:0004
hid-record report of Mi Mouse

Description Wael Nasreddine 2018-08-17 23:21:55 UTC
Created attachment 277917 [details]
lsusb -vvv of 214e:0004

After updating my kernel to 4.18.1, my USB mouse is no longer functional, the pointer does not move although the buttons and the scrolling remained functional. The mouse pointer moves if I use the touchpad.
Comment 1 Wael Nasreddine 2018-08-17 23:22:32 UTC
Relevant bug on NixOS: https://github.com/NixOS/nixpkgs/issues/45165
Relevant bug on Arch: https://bugs.archlinux.org/task/59699
Comment 2 Dmitry Torokhov 2018-08-20 16:36:24 UTC
What was the version that did work?
Comment 3 Wael Nasreddine 2018-08-20 21:28:20 UTC
Dmitry, I have this mouse for two years and it has always worked out of the box. I'm currently on 4.17.15, and it works perfectly.
Comment 4 Benjamin Tissoires 2018-08-27 15:15:26 UTC
Could you attache the report descriptors from the device?
A simple way to do that is to use hid-record[1] as root.

[1] https://bentiss.github.io/hid-replay-docs/
Comment 5 Ranieri Althoff 2018-08-31 06:40:59 UTC
Created attachment 278213 [details]
hid-record report of Mi Mouse

This is the output for hid-record of Mi Mouse (2717:003b) on Wireless 2.4GHz. Over Bluetooth, the results are similar, except that only 1 HID device is reported instead of 4.

It works properly on 4.17.11 and previous but fails on 4.18+, I am specifically testing on 4.18.5
Comment 6 Benjamin Tissoires 2018-08-31 07:19:59 UTC
Thanks. You have the exact same report descriptor than bug #200849.

Now that I re-read it, there is obviously a bug in the code. The intent should be good:
- both buttons and cursor position are reported in the same 'application' collection
- the buttons are attached to a 'physical' mouse collection, when the cursor position is attached to a 'consumer control' collection.

The second point above should not create a secondary input node, when it obviously makes one. So there is a bug. For now, we should probably revert the hid-generic change of f07b3c1da92db1 and make sure this quirk gets fixed in v4.19 or v4.20.
Comment 7 Benjamin Tissoires 2018-08-31 09:37:19 UTC
FYI, patch submitted: https://patchwork.kernel.org/patch/10583471/
Comment 8 Ranieri Althoff 2018-08-31 20:59:24 UTC
Thanks Benjamin. It it matters, I have another 2.4GHz wireless mouse that works properly, but indeed it reports a single device.
Comment 9 Ranieri Althoff 2018-09-09 21:34:28 UTC
Benjamin, I can confirm that your latest patch (the fix, not the revert) is working properly for my device, but I don't know how to report that on patchwork.
Comment 10 Benjamin Tissoires 2018-09-10 08:21:35 UTC
(In reply to Ranieri Althoff from comment #9)
> Benjamin, I can confirm that your latest patch (the fix, not the revert) is
> working properly for my device, but I don't know how to report that on
> patchwork.

There is no real point updating patchwork/the patch itself now. The patch has been accepted and is in Jiri's tree for-19/fixes branch:

It should then be in the next pull request Jiri sends to Linus, and then it will be mainline. So no worries :)