Udev detects an Asrock LED controller as a joystick about systemd

[KayJay7]

BTW, 51-these-are-not-joysticks-rm.rules seems to be terrible workaround...

Yes, @foresto has already opened an issue suggesting better solutions on the repository that maintains the blacklist: denilsonsa/udev-joystick-blacklist#58

[scaronni]

Just hijacking, the ASRock LED Controller issue spins up from this: https://github.com/denilsonsa/udev-joystick-blacklist

Which I included in the Fedora Steam package long time ago to solve users' issues. This of course would be better as an hwdb with quirks and even better fixed properly in the kernel.

Since this has never been fixed in the kernel and the udev rules just touch the device files without changing what udev sees I think I will switch it all to a custom hwdb, at least short term.

[yuwata]

BTW, 51-these-are-not-joysticks-rm.rules seems to be terrible workaround...

[yuwata]

And the better way to workaround such misdetection is updating hwdb.d/60-input-id.hwdb.
Could you submit a patch?

[yuwata]

Should be something like that:

diff --git a/hwdb.d/60-input-id.hwdb b/hwdb.d/60-input-id.hwdb
index eff160cd31..37db06c9d8 100644
--- a/hwdb.d/60-input-id.hwdb
+++ b/hwdb.d/60-input-id.hwdb
@@ -79,3 +79,7 @@ id-input:modalias:input:b0003v068Ep00F2*
 # TEX Shinobi Trackpoint
 id-input:modalias:input:b0003v04D9p0407e0111-e0,1,2,4*
  ID_INPUT_POINTINGSTICK=1
+
+# ASRock LED Controller
+id-input:modalias:input:b0003v26CEp01A2*
+ ID_INPUT_JOYSTICK=0

[KayJay7]

Sure, I can

[foresto]

I notice that the well_known_keyboard_keys array in udev-builtin-input_id.c seems to be a more general approach to solving problems like this. I wonder under what circumstances it would make sense to include some of this device's "keys" (as found by evemu_describe) in that array, rather than making individual device-specific hwdb entries, given that there are dozens of such devices.

I suppose expanding the general approach would have the risk of matching devices that it shouldn't. Does the udev project have a policy for deciding which approach to use?

[foresto]

+# ASRock LED Controller
+id-input:modalias:input:b0003v26CEp01A2*
+ ID_INPUT_JOYSTICK=0

It occurs to me that software looking for ID_INPUT_JOYSTICK without additional logic to interpret its value might treat a "0" string the same as a "1". (This seems reasonable, given that I have never found documentation on this property, and the VAR=1 pattern in software is often used when a variable's presence or non-empty value is all that matters.)

To avoid that problem, perhaps it would make sense to have this rule set it to an empty value instead? (I think removing the property entirely would be ideal, but I don't know if that's possible in a .hwdb file.)

[yuwata]

It occurs to me that software looking for ID_INPUT_JOYSTICK without additional logic to interpret its value might treat a 0 value the same as a 1.

Could you report the issue to an bug tracker of the software?

To avoid that problem, perhaps it would make sense to have this rule set it to an empty value instead?

Yes, an empty string should be supported. Feel free to use ID_INPUT_JOYSTICK= (without value).

[yuwata]

I notice that the well_known_keyboard_keys array in udev-builtin-input_id.c seems to be a more general approach to solving problems like this. I wonder under what circumstances it would make sense to include some of this device's "keys" (as found by evemu_describe) in that array, rather than making individual device-specific hwdb entries, given that there are dozens of such devices.

I suppose expanding the general approach would have the risk of matching devices that it shouldn't. Does the udev project have a policy for deciding which approach to use?

Yeah, maybe. But I am not familiar with what kind of keys should be added there...

[foresto]

It occurs to me that software looking for ID_INPUT_JOYSTICK without additional logic to interpret its value might treat a 0 value the same as a 1.

Could you report the issue to an bug tracker of the software?

I would have to find it first. :) My point is just that it seems likely to exist in multiple places, and avoiding the problem before it happens would be preferable to hunting for every instance of it and then applying patches to each one.

Yes, an empty string should be supported. Feel free to use ID_INPUT_JOYSTICK= (without value).

Great. That ought to be a safer choice.

[KayJay7]

Yes, an empty string should be supported. Feel free to use ID_INPUT_JOYSTICK= (without value).

Even leaving it blank sets the property to 0. Though, among the programs I have tested, only jstest-gtk (which seems to look for /dev/input/js*) and the dolphin emulator (which probably look for the property but not it's value) have mistaken it for a controller.

[foresto]

Even leaving it blank sets the property to 0.

That's surprising, given that these key/value pairs are essentially strings. Why would an empty string be replaced by a "0" string?

If you saw a 0, are you sure it wasn't a stale value? Maybe your updated .hwdb file that sets the empty value hadn't yet been compiled and reloaded?

[foresto]

Maybe a systemd-hwdb update is needed in order to apply your change?

[KayJay7]

It persisted after rebooting. And I have updated it with systemd-hwdb update and udevadm trigger. Maybe the rules in hwdb.d work differently from the ones in rules.d, after all if I run udevadm verify in hwdb.d it shows errors everywhere

[KayJay7]

Wait, I made an error. It does not set it to 0. But it sets it to empty

[KayJay7]

Now with udevadm test i get

DEVPATH=/devices/pci0000:00/0000:00:08.3/0000:10:00.0/usb7/7-1/7-1:1.0/0003:26CE:01A2.0001/input/input2/js0
DEVNAME=/dev/input/js0
MAJOR=13
MINOR=0
SUBSYSTEM=input
ACTION=add
TAGS=:ASRock_Polychrome_USB:seat:uaccess:
ID_INPUT=
ID_INPUT_JOYSTICK=
ID_INPUT_KEY=
CURRENT_TAGS=:ASRock_Polychrome_USB:seat:uaccess:
ID_BUS=usb
ID_MODEL=LED_Controller
ID_MODEL_ENC=LED\x20Controller
ID_MODEL_ID=01a2
ID_SERIAL=ASRock_LED_Controller_A02019100900
ID_SERIAL_SHORT=A02019100900
ID_VENDOR=ASRock
ID_VENDOR_ENC=ASRock
ID_VENDOR_ID=26ce
ID_REVISION=0000
ID_TYPE=hid
ID_USB_MODEL=LED_Controller
ID_USB_MODEL_ENC=LED\x20Controller
ID_USB_MODEL_ID=01a2
ID_USB_SERIAL=ASRock_LED_Controller_A02019100900
ID_USB_SERIAL_SHORT=A02019100900
ID_USB_VENDOR=ASRock
ID_USB_VENDOR_ENC=ASRock
ID_USB_VENDOR_ID=26ce
ID_USB_REVISION=0000
ID_USB_TYPE=hid
ID_USB_INTERFACES=:030000:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usbhid
ID_PATH_WITH_USB_REVISION=pci-0000:10:00.0-usbv2-0:1:1.0
ID_PATH=pci-0000:10:00.0-usb-0:1:1.0
ID_PATH_TAG=pci-0000_10_00_0-usb-0_1_1_0
ID_FOR_SEAT=input-pci-0000_10_00_0-usb-0_1_1_0
run: 'uaccess'

And dolphin still detects it.

(I also tried to unset ID_INPUT_KEY and ID_INPUT because it's not an input device)

[yuwata]

And dolphin still detects it.

Even after udevadm trigger or reboot the machine?

[KayJay7]

Yes, it lists it as evdev/0/Asrock LED Controller

[yuwata]

You mean, that's expected?

[KayJay7]

It's how it detected it before. But it means it still detects it

[foresto]

It looks like Dolphin Emulator developed their own evdev code to use instead of SDL (on linux):

https://github.com/dolphin-emu/dolphin/pull/2681/files

https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/InputCommon/ControllerInterface/evdev/evdev.cpp

From a quick look at the code, I don't see any reference to ID_INPUT_JOYSTICK, which suggests that they're ignoring it entirely. If that's true, then I think one of these things would be needed to solve the problem in Dolphin:

• Rebuild Dolphin with its ENABLE_SDL and ENABLE_EVDEV options set in such a way that SDL is used instead of their custom evdev controller backend. (I think SDL respects ID_INPUT_JOYSTICK.)
• Convince the Dolphin maintainers to make their joystick detection smarter.
• Figure out which part of the driver stack is responsible for exposing this device through evdev (this might be evdev itself or something HID-related; I'm not sure) and work with its maintainers to solve the problem at that level. Depending on where this is done, I imagine it could get rid of the js0 node as well.

---

Edit: This comment in Dolphin's evdev.cpp makes me wonder if the author was unaware of properties like ID_INPUT_JOYSTICK:

// Unfortunately udev gives us no way to filter out the non event device interfaces.
// So we open it and see if it works with evdev ioctls or not.

[KayJay7]

I have opened the PR here

[poettering]

Udev creates the /dev/input/js0 file for the LED controller,

Note that this is wrong/misleading. udev does not create device nodes, the kernel does this entirely on its own, udev then just changes access modes/ACLs and maintains metadata for it.

In this case this means that whatever we do in userspace: the kernel apparently thinks this is a joystick and thus created /dev/input/js0 for it. So to me it appears that this probably should be dealt with in the kernel properly too, since you don't want such a device to show up if the thing is not actually a joystick.

@whot what's the correct way to deal with such devices, so that the kernel doesn't create a JS device for them?

[whot]

@KayJay7: I'm wondering: is this a HID device? Check with hid-recorder from hidtools - if so we might be able to fix it with udev-hid-bpf.

fwiw, please use libinput record instead of evemu because it would've answered that for us :) evemu is effectively unmaintained, libinput record still sees useful features added.

Just hijacking, the ASRock LED Controller issue spins up from this: https://github.com/denilsonsa/udev-joystick-blacklist

@scaronni: fwiw, libwacom also ships a hwdb to explicitly mark every known tablet as ID_INPUT_TABLET and remove ID_INPUT_JOYSTICK. See 65-libwacom.hwdb on your local machine, it's probably there.

and btw, I'd be nice if you could update generate_rules.py to also print a comment with the device name, makes debugging a bit easier than just staring at a bunch of hex numbers :)

Also, if those are objectively wrong defaults it'd be great to add the overrides to 60-input-id.hwdb so we don't need a separate repo for those.

@whot what's the correct way to deal with such devices, so that the kernel doesn't create a JS device for them?

drivers/input/joydev.c seems to have its own detection system including a blacklist so I guess it'd have to be added to that. From a quick check this device falls "afoul" of the ABS_THROTTLE check - because of that it's handled as joystick device. That check is incredibly simple but then again it's understandable - it's easier to create a /dev/js file and have userspace ignore it than make userspace handle a device that's not exposed at all.

This comment in Dolphin's evdev.cpp makes me wonder if the author was unaware of properties like ID_INPUT_JOYSTICK:

Or an even simpler approach, esp. if you don't want to trust the properties:

sysname = udev_device_get_sysname(device);
if (strncmp("event", sysname, 5)) { ... }

unfortunately issues are disabled in the dolphin repo.

[KayJay7]

@KayJay7: I'm wondering: is this a HID device? Check with hid-recorder from hidtools - if so we might be able to fix it with udev-hid-bpf.

With hid-recorder I get this: hid-record.log
Those events are triggered when I change settings in OpenRGB.

fwiw, please use libinput record instead of evemu because it would've answered that for us :) evemu is effectively unmaintained, libinput record still sees useful features added.

With libinput record I get this: libinput-record.log
Here it doesn't show any event when I change settings, I don't know if it means something.

[KayJay7]

@whot : For comparison, this is what the other LED controller (the corsair one, which doesn't pretend to be a joystick) looks like in hid-record: hid-record-corsair.log. Those events are also triggered when I change settings, much like the other controller. And it doesn't show up in libinput record which I guess makes sense since it's not an input device.