Hi! > > Comments from previous review were not addressed. > > > > Most importantly, this is not a way to do kernel interface. We want > > reasonable interface that can be documented and modified as needed. We > > want to pass /dev/input to userspace, not raw HID. This is not ok. > > There are already 2 endless discussions about this: > > https://lore.kernel.org/all/1fb08a74-62c7-4d0c-ba5d-648e23082dcb@xxxxxxxxxxxxxxxxxxx/ > > https://lore.kernel.org/all/73c36418-34d6-46cf-9f10-6ca5e569274f@xxxxxxxxxxxxxxxxxxx/ > > And a shorter one before that: > > https://lore.kernel.org/all/30cbbf20-08cf-a69b-4f58-359a9802e86f@xxxxxxxxxxxxxxxxxxx/ > > The brief: > > - LampArray is a standard that will hit the Linux world anyway. Maybe. Still have to see device implementing that. LampArray will still need /sys/class/leds for compatibility. LampArray still does not solve effects. More importantly, it is not okay to say "kernel interface is specified by that crazy document from 3rd party". > - The alternative proposal via a led matrix does not even really fit > keyboards, and does not at all fit all other device types. We are solving keyboards, not the other device types. The other devices can likely be handled by existing /sys/class/leds interfaces. > Hans and Benjamin already agree with me that LampArray is the way to go. > > So after over 2 years can I please have a final decision on how to implement this? For final decisions, you'd have to talk to Linus. (And sorry for the delay, btw). If you want to move this forward, place a driver in drivers/leds/keyboard. Implement /sys/class/leds interface, but make sure interface is clearly separated from the code talking to the firmware. Then we can review that, perhaps merge, so users will have something, and decide what interface to use for per-key control. LampArray is no-go. Other options are open. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates.
Attachment:
signature.asc
Description: PGP signature
