Re: [PATCH] HID: logitech-hidpp: support Color LED feature (8071).

On Wed, Mar 23, 2022 at 11:24:18PM +0100, Bastien Nocera wrote:

On Wed, 2022-03-23 at 21:22 +0000, Filipe Laíns wrote:

quoted

On Tue, 2022-03-08 at 16:50 -0700, Manuel Schönlaub wrote:

quoted

The HID++ protocol allows to set multicolor (RGB) to a static
color.
Multiple of such LED zones per device are supported.
This patch exports said LEDs so that they can be set from
userspace.

Signed-off-by: Manuel Schönlaub <redacted>
---
 drivers/hid/hid-logitech-hidpp.c | 188
+++++++++++++++++++++++++++++++
 1 file changed, 188 insertions(+)

*snip*

Hi Manuel,

Thanks for putting this forward, although I am not sure if this is
the best way
to handle this.

Before anything, could you elaborate a bit on what lead to you
wanting this?

There are a couple of reasons why merging this in the kernel might be
problematic.

1) I don't think we will ever support the full capabilities of the
devices, so
configuration via userspace apps will always be required, and here we
are
introducing a weird line between the two.

2) There is already an ecosystem of userspace configuration apps,
with which
this would conflict. They might not be in the best maintenance state
due to lack
of time from the maintainers, but moving this functionality to the
kernel, which
is harder change, and harder to ship to users, will only make that
worse.

There's already an API for LEDs in the kernel, why shouldn't it be used
to avoid user-space needing to know how to configure Logitech, and
every other brand of keyboards?

systemd has code to save and restore LED status, as well as code to
change the level of backlight. I can imagine that it wouldn't take much
to make it aware of RGB LEDs so it handles them properly, whether it's
for Logitech, or another brand of keyboards, or laptops.

Teaching systemd-backlight about mulicolor backlights might be a nice project
too. But their use case seems to be more about screen backlights as it seems.
Did I overlook something here?

Oh and yeah, IMHO another argument could be that obviously at some point
the LED management could be removed from those user space tools, as the
kernel would already know about them.

After all the LED class devices should be there for a reason ;-)

Cheers,

Manuel