Ooops, s/explicitly enabled\?/explicitly disabled\?/

Hmm, I think we never supported bluetooth keyboards, even with the old
keymap stuff:
  http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/keymap/95-keymap.rules?id=v205#n11

How would a match on the HID device look like?

Before with /lib/udev/keymap it was pretty easy to write a custom udev rule to apply a keymap:

SUBSYSTEM=="input", \
  ATTRS{name}=="ThinkPad Compact Bluetooth Keyboard with TrackPoint", \
  RUN+="keymap $name /etc/udev/keymaps/thinkpad-bluetooth-keyboard.map"

...so I wouldn't have noticed that the default rules don't play around with bluetooth keyboards. NB: my remappings themselves are not worthy of upstream, just my own odd quirks.

Now with hwdb I have 2 levels of indirection to mine through. I presume adding my own rule (and associated hwdb entry) like this would work:

SUBSYSTEM=="input", \
  ATTRS{name}=="ThinkPad Compact Bluetooth Keyboard with TrackPoint", \
  IMPORT{builtin}="hwdb 'keyboard:custom:compact-bluetooth-keyboard'", \
  RUN{builtin}+="keyboard"

However, adding this udev rule and inventing my own namespace seems unnecessary. A hwdb mapping for bluetooth devices, or bluetooth devices using using the "keyboard:name:" mapping would mean I just have to add entries to hwdb, as with other keyboard types.

Unfortunately I am currently away, however will suggest a patch next week.

Created attachment 106011 [details] [review]
udev: Allow key mapping for bluetooth keyboards

The attached patch allows me to do "keyboard:hid:b*5g*v*17EFp*6048" for my keyboard in a .hwdb file.

I notice that bluetoothctl reports "Modalias: usb:v17EFp6048d0309" for the keyboard, but I can't find a node in /sys that matches this modalias that we can use. having the "usb:" prefix is somewhat confusing anyway.

Looks legit. Kay?

(In reply to Zbigniew Jedrzejewski-Szmek from comment #6)
> Looks legit. Kay?

I don't remember why we blacklisted bluetooth and we should not remove that
without finding out first.

But, I talked to David Herrmann, and we think, we could just match all HID
devices, instead of making a specific rule for bluetooth HID devices only.

> I don't remember why we blacklisted bluetooth and we should not remove that
> without finding out first.

I did try digging into history to work this out at the time, but didn't find anything conclusive.

> But, I talked to David Herrmann, and we think, we could just match all HID
> devices, instead of making a specific rule for bluetooth HID devices only.

That'd make a lot of sense IMO.

Yep, I don't see anything interesting in git history or on the mailing list either.

I guess we want the rule to be as narrow as possible to avoid unnecessary processing on devices that cannot match. Kay, David, you're the experts here.
How should the general rule for HID devices look?

Jamie, can you update your rule to apply to abitrary hids?

This is now fixed in -git. To add bluetooth devices, please provide the MODALIAS from /sys/class/input/inputX/uevent. We only match on name/dmi information if absolutely necessary.

I will now mark this issue as resolved. Jamie, please feel free to paste your device information here and I will add it.

David, thanks! Apologies for not getting around to a new patch, this slipped off my queue. The /sys/class/input/input*/uevent file for my keyboard has "MODALIAS=input:b0005v17EFp6048e0309-...", so this should work fine.

There isn't any generic remapping to do, so no need to add anything (any generic remapping is handled in the HID driver). However, it's nice to have the hook to handle my own quirks.

Thanks again,