On Wed, 18 Aug 2021 at 18:48:45 +0200, Martin Pieuchot wrote: > Regarding the introduction of a separate wskbd(4) this can be seen as an > intermediate step. Having this logic in ukbd(4) implies revisiting the > way reportID are mapped to USB drivers, which is still a bit of a hack > when it comes to supporting multiple of them. Having a simpler driver > like ucc(4) can help us figure out out to support more "special" keys > without having to deal with the HID logic at the same time. > > It would be great if users of usbhidaction(1) could tell us if this > introduce any regression and/or if other keys could be supported.
I used usbhidaction for a Bluetooth audio device that supported passing button presses through. https://jcs.org/2020/11/18/openbsd_btaudio#responding-to-headphone-buttons $ cat .usbhidaction.conf Consumer:Play/Pause 1 ~/bin/music playpause Due to the lack of an XF86Audio* keysym that is both "play/pause", ucc can only map it to just XF86AudioPlay. It's no big deal for me to adapt though, and I'm happy to see a driver do all of this automatically. Though it would be nice to find a way to pass any unsupported buttons through, even if they are just no-named keysyms that would at least allow a program to bind/react to them.
