Created attachment 164476 [details] Xorg.0.log output under Slackware 14.1 My (USB) Logitech Illuminated Keyboard works fine under Linux, but not so fine under FreeBSD. Under Linux I get keyboard events for multimedia keys - XF86AudioLowerVolume as an example. I don't get them in FreeBSD. I thought at first that this was bad handling of the uhid in FreeBSD, but very recently I noticed that Linux appears to see roughly the same things FreeBSD did. To clarify this, my initial workaround in FreeBSD was to hack up a version of usbhidaction that pretended "range" values from uhids didn't exist. This done, I was able to get discrete values for media keys that I could interpret and act on appropriately. Now, looking at the same keyboard under Linux, I see that the uhid that attaches alongside the keyboard is seen as delivering ranges there too, and yet, something in there is delivering key events when the uhid's keys are hit. I'm not sure where to file this, so I'm doing it under x11/xorg for now. Attachment is the relevant excerpt from my Xorg.0.log under Slackware.
The Xorg server under Linux uses /dev/input/event? device and xf86-input-evdev driver. Under FreeBSD it uses /dev/{kbdmux,ukbd,atkbd}? and (still) xf86-input-keyboard. At the moment, you need to use usbhidaction aor sysutils/uhidd to make multimedia keys work.
usbhidaction is problematic in this case. The issue I had with using usbhidaction is that I needed to patch it, as it was getting "range" values back from my multimedia keys by default. I'd want to test this, but my ugly hack to get readable values from the multimedia keys was: $ diff -u usbhidaction.c* --- usbhidaction.c 2015-12-22 16:05:40.508177432 -0500 +++ usbhidaction.c.patched 2015-12-22 16:06:45.804170602 -0500 @@ -447,7 +447,7 @@ cmd->item = h; cmd->name = strdup(name); cmd->action = strdup(action); - if (range) { + if (range & 0) { if (cmd->value == 1) cmd->value = u - lo; else At least, that's my recollection. I went from there to thinking that we were misclassifying the device in the kernel, but after that I noted Xorg.0.log on Linux where evdev is evidently also seeing a device that can present a range of values, but was doing the right thing with it. Is moving to evdev a possibility, or is it hopelessly tied to Linux? Do we instead want to make this work with FreeBSD's usbhidaction without modification? I remember starting to look for a quirk table or similar I could update to prevent this device from being detected as presenting ranged values, but I hadn't found the right thing by the time I gave up.
(In reply to Mason Loring Bliss from comment #2) https://wiki.freebsd.org/201510DevSummit/GraphicsStack "Jakub Klama made a port of evdev which is quite stable. We discussed this with him, he will put it in Phabricator as soon as he has spare time." EvDev will be integrated into FreeBSD, exact time table is not known. If you want more information you could contact Jakub Klama. Have you tried using uhidd? Btw, uhidd is a horrible hack in itself, because it cannot work reliably with the kernel hid drivers. One would have to prevent ukbd/ums/etc from being attached to make sure uhidd functions properly. Uhidd is able detach kernel hid drivers, but I've heard this might cause issues such as crashing in FreeBSD newer than 8.x.
FreeBSD is better off this way. Sorry for the bother.
For multimedia keys see https://wiki.freebsd.org/uhidd evdev FreeBSD (both in-kernel or via webcamd) doesn't support USB HID devices at all.
FWIW, uhidd has serious problems that result in erratic keyboard behaviour - misinterpreting keypresses, adding in phantom keystrokes. It's not in its present form a sufficient solution.
Did you try to use only -o (cc_attach) + -U (forced_attach) ? There's no need to use uhidd keyboard driver if you just want multimedia keys.
(In reply to Jan Beich from comment #5) > ...doesn't support USB HID devices at all. ^^^ "generic" is the missing word. Multimedia keys on USB keyboards, USB joysticks, etc. are handled by uhid driver on both Linux and FreeBSD. However, FreeBSD doesn't recognize many HID report descriptors thus usbhidaction(1) rarely works. webcamd can fill this gap but requires porting effort. OTOH, evdev in kernel is limited in what it supports: kbdmux, atkbd (x86), ukbd, ums, ti_adc (arm), rpi_ft5406 (arm). Of note, uhid(4) is not supported by evdev but can be emulated[1]. [1] https://github.com/jiixyj/evdevfbsd/blob/master/backend-uhid.c
Looking more, webcamd builds HID drivers nowadays. I'm probably several years out of date on how many input devices it supports. ;)