On Oct 02 2024, Armin Wolf wrote:

Am 02.10.24 um 10:42 schrieb Benjamin Tissoires:

quoted

On Oct 01 2024, Werner Sembach wrote:

quoted

Hi Armin,

Am 01.10.24 um 18:45 schrieb Armin Wolf:

[...snipped...]

quoted

quoted

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.

quoted

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?

hmm, we can, but only a couple of drivers would be valid: hid-multitouch
and hid-generic AFAICT. All of the others are device specific, so
allowing anybody to map a device to it might not work (if the driver
requires driver_data).

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.

that coud be an option. But in that case, I wonder if the LampArray
implementation should be done in hid-led or in hid-input.c (the generic
part). I don't know if the new devices will export one HID device for
LampArray and one other for the rest, when the rest might need a
specific driver.

Anyway, thanks for the tip :)

Cheers,
Benjamin

Thanks,
Armin Wolf

quoted

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@kernel.org/T/#t (local)