Hi
Am 24.07.24 um 19:36 schrieb Pavel
Machek:
Hi!IMO working with the HID LampArray is the way forward. So I would suggest to convert any non-HID RGB "LED display" that we are talking about as a HID LampArray device through `hid_allocate_device()` in the kernel. Basically what you are suggesting Hans. It's just that you don't need a formal transport layer, just a child device that happens to be HID. The next question IMO is: do we want the kernel to handle such machinery? Wouldn't it be simpler to just export the HID device and let userspace talk to it through hidraw, like what OpenRGB does?That's already part of my plan: The kernels main goal is to give devices a LampArray interface that don't have one already (e.g. because they are no HID devices to begin with). The actual handling of LampArray will happen in userspace. Exception is that maybe it could be useful to implement a small subset of LampArray in a generic leds-subsystem driver for backwards compatibility to userspace applications that only implement that (e.g. UPower). It would treat the whole keyboard as a single led.
LampArray also gives the HID keycode, if applicable, for keyboard
leds.
It's the InputBinding field in the LampAttributesResponseReport, see HID Usage Tables v1.5 -> 26.3 Lamp Attributes Report.
Kind regards,
Werner
(ps sorry for resend @pavel, hit
reply instead of reply all the first time)
Are you sure LampArray is good-enough interface? OpenRGB exposes keycode-to-LED interface, how will that work with LampArray? Best regards, Pavel
