Bug 200849 - Kensington Expert Mouse Wireless trackball not working
Summary: Kensington Expert Mouse Wireless trackball not working
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-17 23:54 UTC by Zach Nedwich
Modified: 2018-09-10 09:51 UTC (History)
7 users (show)

See Also:
Kernel Version: 4.18.1.1
Tree: Mainline
Regression: No


Attachments
lspci (25.48 KB, text/plain)
2018-08-17 23:54 UTC, Zach Nedwich
Details
hid-recorder capture (1.68 KB, text/plain)
2018-08-27 15:57 UTC, Santi Villalba
Details
hid-recorder, translated (6.12 KB, text/plain)
2018-08-27 16:11 UTC, Benjamin Tissoires
Details

Description Zach Nedwich 2018-08-17 23:54:32 UTC
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
Comment 1 Santi Villalba 2018-08-18 12:13:14 UTC
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.
Comment 2 Leif Huhn 2018-08-22 20:40:26 UTC
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.
Comment 3 Leif Huhn 2018-08-22 23:36:51 UTC
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.
Comment 4 Dmitry Torokhov 2018-08-23 20:39:22 UTC
I'd look at Benjamin updates creating separate input devices for each HID collection.
Comment 5 Leif Huhn 2018-08-23 23:48:32 UTC
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>
Comment 6 Wael Nasreddine 2018-08-24 15:20:47 UTC
Duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=200847
Comment 7 Benjamin Tissoires 2018-08-27 15:15:57 UTC
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/
Comment 8 Santi Villalba 2018-08-27 15:57:02 UTC
Created attachment 278133 [details]
hid-recorder capture

I attach the report of hid-recorder, let me know if it is good enough.
Comment 9 Benjamin Tissoires 2018-08-27 16:11:50 UTC
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.
Comment 10 Benjamin Tissoires 2018-08-31 07:21:38 UTC
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.
Comment 11 Benjamin Tissoires 2018-08-31 09:37:36 UTC
FYI, patch submitted: https://patchwork.kernel.org/patch/10583471/
Comment 12 Zach Nedwich 2018-08-31 09:43:02 UTC
Thank-you Benjamin, appreciate the quick turn-around.
Comment 13 Leif Huhn 2018-09-05 22:24:10 UTC
It is now working for me on 4.18.6-arch1-1-ARCH.
Comment 14 Zach Nedwich 2018-09-10 09:51:31 UTC
Tested and working on patched 4.18.7 for me, thanks!

Note You need to log in before you can comment on or make changes to this bug.