A4TECH Bloody J90s mouse does not work correctly in 2000 Hz mode

Mouse in question: https://www.bloody.com/en/product.php?pid=10&id=230

I was told that this is probably 'a kernel bug than in that it doesn't merge the device correctly' and to report here first.

The mouse works correctly under Windows under any response rate.
The mouse works correctly under Linux on 1kHz.
The mouse does not work correctly under Linux on 2kHz.

At that 2kHz, the mouse does not register slow movements to left and up, but works fine down and right. This happens in both Wayland and X. I am testing on Arch Linux with kernel 5.10.16 under Plasma 5.21.

The mouse looks to be working correctly from 'evtest' logs.
There's no logs from 'libinput debug-events' when moving slowly left-up.

Using hid-recorder, it turns out there's two hidraw devices. One has about half the movements, the other has the other half.

Side note: The DID of the device does NOT indicate absolutely anything about the hardware. It is randomly generated for each unique mouse by the vendor software.

Here's a quick video showcasing the issue with hid-recorder open on both hidraw devices: 2021-02-18_10-29-49.mkv

changed the description

Ouch, I now understand why it is a 'bloody' mouse :)

First time I ever see that. Could you submit a hid-recorder log with both hidraw nodes interleaved? You should be able to run that simply by hid-recorder /dev/hidraw12 /dev/hidraw13.

This is going to be very interesting to fix in the kernel. I do hope they are not using 2 separate USB endpoints to multiply by 2 the transfer rate, because the kernel side implementation will get messier.

Cc: @whot

Could you submit a hid-recorder log with both hidraw nodes interleaved?

This is me moving top left, bottom right then doing a few fast circles. bloody.zip

I do hope they are not using 2 separate USB endpoints to multiply by 2 the transfer rate

I don't get how they're doing this or how this is supposed to help anything at all with USB standard having 1000Hz max polling rate...

I don't get how they're doing this or how this is supposed to help anything at all with USB standard having 1000Hz max polling rate...

marketing.

I see they spared no expense and left the device name at COMPANY USB Device. Encouraging... :)

Actually, the device name was correctly filled out in older versions of the firmware. But not in the flashing mode of the firmware.

At some point, they reversed the two, and now you can only see the correct device name in flashing mode (i.e. never, under normal usage).

There's lots more bonkers things about these mice, the firmware has a random number generator for the DRM. Yes, this mouse has DRM for a DLC you can buy to unlock the full features.

It also generates an ID which the Device ID is based on (for the license), making all hardware detection via vendor:device useless.

If the activation server decides your license is pirated, you get redirected to a ru.txt page (and the FW is deactivated again), presumably because it was first broken by the russians.

To top it all off, the vendor software sends identifying information about your computer (mac, username, and other things a mouse vendor totally needs to know) over HTTP (but AES encrypted) on each launch, which I am sure is very GDPR friendly.

I could go on, I have been using their mice for a while now :D

you're really selling it here... :)

Thanks for the logs, the cause of the bug is this:

event28 - COMPANY  USB Device Mouse: not tagged as supported input device

We have 6 event nodes in total, two of which produce events. The second one however looks like this:

    # Name: COMPANY  USB Device Mouse
    # ID: bus 0x3 vendor 0x9da product 0x5ee9 version 00
    # Supported Events:
    # Event type 0 (EV_SYN)
    # Event type 2 (EV_REL)
    #   Event code 0 (REL_X)
    #   Event code 1 (REL_Y)

Because it doesn't have BTN_LEFT, udev doesn't tag it with ID_INPUT_MOUSE. libinput thus ignores the device since it cannot tell what type it is. As workaround for now, the following hwdb entry in 60-input-id.hwdb will do:

id-input:modalias:input:b0003v09DAp5EE9*
  ID_INPUT_MOUSE=1

See this post for help.

log files

Analysis of the logs from #33 (comment 809176). The device does indeed alternate between the two hid devices:

D: 0
#  Button: 0  0  0  0  0  0  0  0 | X:     -1 | Y:     -1 | Wheel:    0 
E: 000003.027143 6 00 ff ff ff ff 00
D: 1
# ReportID: 4 / X:     -2 | Y:     -2 
E: 000003.027214 5 04 fe ff fe ff

A grep for ReportID: shows that the second device has the full range of x/y movements, it's not limited to just one direction. Same is true for a grep of Button: which is the first device's human-readable output.

What's a bit bonkers is that the first set of events are all from device 0, going right-up (x/y are always 0 or 1). The second set of events starting at 000002.523155 are all down/left and exclusive from device 1 with the same 0 or 1 value range.

The interleaved events start at 000002.934148 and there's no specific pattern here. The events don't cancel each other out either. So right now I don't know how the fw picks which device to send through but it doesn't matter too much.

Theoretically it's like moving two mice at the same time, the input stack can handle this situation already (although at least in X it'll flood the client with XIDeviceChanged events). Overall though there's nothing wrong per-se here except for the missing device identification.

mentioned in merge request libinput/libinput!576 (merged)