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)
(pps resend a second time because Thunderbird did HTML e-mail)
Are you sure LampArray is good-enough interface? OpenRGB exposes
keycode-to-LED interface, how will that work with LampArray?
Best regards,
Pavel
