On Thu, May 12, 2022 at 3:48 PM Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > On Thu, May 12, 2022 at 03:35:00PM -0700, Pablo Ceballos wrote: > > On Thu, May 12, 2022 at 3:53 AM Jiri Kosina <jikos@xxxxxxxxxx> wrote: > > > On Thu, 12 May 2022, Dmitry Torokhov wrote: > > > > I am curious, could not this be achieved without a kernel driver by > > > > simply using udev to map this usage code to KEY_RESERVED? > > > > > > Hmm, good point, using KEY_RESERVED mapping to achieve the key being > > > actually ignored didn't immediately occur to me. > > > > > > Pablo, could you please verify that it behaves in the expected way, and > > > confirm that we could drop the 'driver' in favor of udev rule? Jiri, this driver can be dropped from 5.19. The udev rule works just as well. > > > > I think I've achieved the same result by adding the following to udev > > hwdb. Dmitry, is this what you had in mind, or is there a better way > > of doing this? > > > > evdev:input:b0003v18D1p8001* > > KEYBOARD_KEY_b002f=reserved > > No, that is exactly what I had in mind, thank you. Please submit this > entry to upstream systemd/udev project (and we can cherry-pick it into > our udev as well). The pull request is here: https://github.com/systemd/systemd/pull/23372 > > In general I think we should try to avoid trivial "fixup" HID drivers if > it is possible. I also wondered if we could be supplying fixed-up HID > descriptors via request_firmware() for HID devices. Pablo
