Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

From: Armin Wolf
Date: Wed Oct 02 2024 - 05:28:00 EST


Am 02.10.24 um 10:42 schrieb Benjamin Tissoires:

On Oct 01 2024, Werner Sembach wrote:
Hi Armin,

Am 01.10.24 um 18:45 schrieb Armin Wolf:
[...snipped...]
Why not having a simple led driver for HID LampArray devices which exposes the
whole LampArray as a single LED?
Yes that is my plan, but see my last reply to Benjamin, it might not be
trivial as different leds in the same LampArray might have different max
values for red, green, blue, and intensity. And the LampArray spec even
allows to mix RGB and non-RGB leds.
If userspace wants to have direct control over the underlying LampArray device,
it just needs to unbind the default driver (maybe udev can be useful here?).
There was something in the last discussion why this might not work, but i
can't put my finger on it.
We recently have the exact same problem, so it's still fresh in my
memory. And here are what is happening:
- you can unbind the driver with a sysfs command for sure
- but then the device is not attached to a driver so HID core doesn't
expose the hidraw node
- you'd think "we can just rebind it to hid-generic", but that doesn't
work because hid-generic sees that there is already a loaded driver
that can handle the device and it'll reject itself because it gives
priority over the other driver
- what works is that you might be able to unload the other driver, but
if it's already used by something else (like hid-multitouch), you
don't want to do that. And also if you unload that driver, whenever
the driver gets re-inserted, hid-generic will unbind itself, so back
to square one

So unless we find a way to forward the "manual" binding to hid-generic,
and/or we can also quirk the device with
HID_QUIRK_IGNORE_SPECIAL_DRIVER[0] just unbinding the device doesn't
work.

Cheers,
Benjamin

I see, maybe we can add support for the driver_override mechanism to the HID bus?
Basically userspace could use the driver_override mechanism to forcefully bind hid-generic
to a given HID device even if a compatible HID driver already exists.

Thanks,
Armin Wolf

PS: brain fart:
if HID LampArray support (whatever the implementation, through Pavel's
new API or simple LED emulation) is in hid-input, we can also simply add
a new HID quirk to enable this or not, and use that quirk dynamically
(yes, with BPF :-P ) to rebind the device...

[0] https://lore.kernel.org/linux-input/20241001-hid-bpf-hid-generic-v3-0-2ef1019468df@xxxxxxxxxx/T/#t