Thoughts on supporting the udev hardware database

[TAAPArthur]

I had the fortunate experience of having my keyboard report keys greater than X can handle. Of course this wasn't a problem with Arch/udev because it was handled by the hwdb

In my case a file like this in etc/udev/hwdb.d/90-thinkpad-keyboard.hwdb was all that was needed:

evdev:name:ThinkPad Extra Buttons:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
 KEYBOARD_KEY_49=playpause

To me the ideal is to be able to reuse the files so we don't have to re-setup every device.

Attempt 1

And I noticed form udevadm info that KEYBOARD_KEY_49 property appeared along with the ID_INPUT_KEYBOARD which udev-zero sets. So I was thinking we could just parse these database files and set the properties ourselves for the matching devices. For each device, we'd just have to compare the regex in the database file to one of the 3 patterns defined here. Seems straightforward enough and have a draft ready... However when I tried to manually set the KEYBOARD_KEY_49 property in udev_device.c, I didn't see an effect. Open to suggestions.

Attempt 2

The arch wiki details on how to manually remap keycodes via setkeycodes. It is easy enough to find all hwdb files, parse then and manually set the keycodes. The script could be run standalone as setkeycodes affects global mapping and isn't per device.

And while I was working on this, I started wondering if anyone really cared. I think being able to change mappings per device is cool in theory, but don't have any hardware where a global change wouldn't suffice. Also, although the udev database allows some extra keys to be recognized, they still report the wrong keysym by default. And if you want to modify the keyboard layout to have the correct keysyms, having a startup file to explicitly remap the keycodes seems pretty reasonable.

Udev hwdb interface isn't implemented. pciutils and usbutils will not display any meaningful info.

So is lack of hwdb really a con? lspci from pciutils displays meaningfull info for me. I could see a benefit if one wanted to set some static configuration for a device at the libinput layer.

Anyways was curious if anyone else put thought into this and/or knew what I was doing wrong in my first attempt

[illiliti]

However when I tried to manually set the KEYBOARD_KEY_49 property in udev_device.c, I didn't see an effect.

Because these (internal and unstable!) properties used by udev daemon to set/remap keys. We don't have udev daemon, therefore key remapping functionality is out of scope(as per readme). Feel free to write key remapping daemon/program that would be compatible with udev hwdb files. See also: https://github.com/rvaiya/keyd

lspci from pciutils displays meaningfull info for me.

Have you tried compiling pciutils with udev support?

[TAAPArthur]

properties used by udev daemon to set/remap keys.

Is that how it works? The properties were visible to libinput so I thought/hoped it did something smart and it could be set once and just work. Sigh.

Feel free to write key remapping daemon/program that would be compatible with udev hwdb files.

I was planning to... or well I have, but don't think it is a good solution (although it is a startup file rather than a daemon). Seems far easier to just explicitly set the desired mapping. I agree with you that support isn't worth it. But lack of support was listed as a con so I was wondering what "feature(s)" I was missing out on without it. Other than key remapping, I'm not aware of any and only became aware of it because some keys weren't working.

Have you tried compiling pciutils with udev support?

Don't think so. Was (basically) using the kiss default. Was just pointing out that lspci can provide meaningful info.

So I'm just trying to gauge what the benefit would be for implemented something like hwdatabase. If the only issue is that programs like lspci won't provide useful info only when compiled with udev support, it seems like there aren't in benefits to implementing it.

[illiliti]

Is that how it works?

Yeah, udev obviously does more than just /dev management.

But lack of support was listed as a con

Note that udev_hwdb interface != hwdb support. The lack of udev_hwdb support was listed as a con because standard udev provides it, while libudev-zero doesn't. I decided to not implement udev_hwdb because it was deprecated and absorbed by systemd(see sd_hwdb), and it is mostly used to lookup meaningful(vendor/device) name of device by modalias. Nothing prevents you from simply parsing pci/usb ids by hand to get those names(i'm looking at you, usbutils)

it seems like there aren't in benefits to implementing it.

Very true. udev_hwdb isn't needed at all and smells like over-engineering.

[TAAPArthur]

Yeah, udev obviously does more than just /dev management.

Well thanks for saving me from digging through udev code to reach that conclusion.

Very true. udev_hwdb isn't needed at all and smells like over-engineering.

Well thanks for all the info. That more than answers the questions I had.

[TAAPArthur]

Turns out simply remapping keycodes is really easier and doesn't require a daemon. Have a working script that remap arbitrary keycode A to arbitrary keycode B.