Hi,
Am 02.10.24 um 10:31 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
Hi Benjamin,
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
[...]
PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
all of the requirements here:
- need to be dynamic
- still unsure of the userspace implementation, meaning that userspace
might do something wrong, which might require kernel changes
Well the reference implementetion for the arduiono macropad from microsoft
ignores the intensity (brightness) channel on rgb leds contrary to the HID
spec, soo yeah you have a point here ...
Heh :)
- possibility to extend later the kernel API
- lots of fun :)
You advertise it good ;). More work for me now but maybe less work for me
later, I will look into it.
Again, I'm pushing this because I see the benefits and because I can
probably reuse the same code on my Corsair and Logitech keyboards. But
also, keep in mind that it's not mandatory because you can actually
attach the BPF code on top of your existing driver to change the way it
behaves. It'll be slightly more complex if you don't let a couple of
vendor passthrough reports that we can use to directly talk to the
device without any tampering, but that's doable. But if you want to keep
the current implementation and have a different layout, this can easily
be done in BPF on top.
Cheers,
Benjamin
[0] https://lore.kernel.org/linux-input/20241001-hid-bpf-hid-generic-v3-0-2ef1019468df@xxxxxxxxxx/T/#t
Thinking about the minimal WMI to HID today, but found a problem: a HID feature
report is either strictly input or output afaik, but the WMI interface has both
in some functions.
How would I map that?
If I split everything in input and output the new interface wouldn't actually be
much smaller.
Also what would I write for the usage for the reserved padding in the report
descriptor. Usage: 0x00?
best regards,
Werner
