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.
Relevant bug on NixOS: https://github.com/NixOS/nixpkgs/issues/45165
Relevant bug on Arch: https://bugs.archlinux.org/task/59699
What was the version that did work?
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.
Could you attache the report descriptors from the device?
A simple way to do that is to use hid-record as root.
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
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.
FYI, patch submitted: https://patchwork.kernel.org/patch/10583471/
Thanks Benjamin. It it matters, I have another 2.4GHz wireless mouse that works properly, but indeed it reports a single device.
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.
(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
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 :)