Created attachment 277919 [details] lspci Hi all, I've got a Kensington trackball mouse, running a 'cat -A /dev/input/mouse0' gets me some output for the buttons and scroll ring, but the actual trackball aka pointer move produces no output, nor does it move the cursor. lspci dump attached. Connected via USB dongle rather than bluetooth. Works okay in 4.17.14. Distro is voidlinux. Many thanks, Zach Nedwich
Same problem here: also connected via dongle, buttons work but pointer does not. In 4.17 it works, in 4.18 it does not. Seen in both a laptop and a desktop.
I'm having the same issue. I'm planning on testing the 4.18-rcX kernels tonight to see which one introduced the issue. I also tried connecting via bluetooth and I had the same problem as with the dongle, btw.
The problem is present in 4.18.0-rc1. I see that in the release notes for -rc1: Dmitry Torokhov (1): input updates Greg KH (5): USB and PHY updates char/misc driver updates driver core updates tty/serial updates staging/IIO updates Jiri Kosina (2): livepatching fixlet HID updates I might do some bisecting if my environment cooperates.
I'd look at Benjamin updates creating separate input devices for each HID collection.
Yes! That's definitely it. I just finished bisecting to f07b3c1da92db108662f99417a212fc1eddc44d1 is the first bad commit commit f07b3c1da92db108662f99417a212fc1eddc44d1 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Tue Apr 24 10:04:33 2018 +0200 HID: generic: create one input report per application type It is not a good idea to try to fit all types of applications in the same input report. There are a lot of devices that are needing the quirk HID_MULTI_INPUT but this quirk doesn't match the actual HID description as it is based on the report ID. Given that most devices with MULTI_INPUT I can think of split nicely the devices inputs into application, it is a good thing to split the devices by default based on this assumption. Also make hid-multitouch following this rule, to not have to deal with too many input created. While we are at it, fix some checkpatch complaints about converting 'unsigned' to 'unsigned int'. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=200847
Could you attach 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/
Created attachment 278133 [details] hid-recorder capture I attach the report of hid-recorder, let me know if it is good enough.
Created attachment 278135 [details] hid-recorder, translated This is the parsed version of your recorder. The problem is that the buttons are indeed reported as pointer, while the coordinates and the other buttons are reporter as "Consumer Control". This looks like a firmware bug. I'll see what is the best solution to fix this.
After receiving the exact same report descriptor in bug #200847, I think I realized that my patch is at fault. I'll submit a partial revert and ensure those mice are properly treated when I re-enable the fixed quirk.
FYI, patch submitted: https://patchwork.kernel.org/patch/10583471/
Thank-you Benjamin, appreciate the quick turn-around.
It is now working for me on 4.18.6-arch1-1-ARCH.
Tested and working on patched 4.18.7 for me, thanks!