On Wed, Aug 18, 2021 at 12:01:53PM -0500, joshua stein wrote: > 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.
I'm currently looking into what hid-input in Linux does while encountering unknown keys.
