On Oct 02 2024, Armin Wolf wrote: > 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? 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 > > > 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
