Re: [PATCH] leds: rgb: Implement per-key keyboard backlight for several TUXEDO devices

From: Werner Sembach
Date: Thu Oct 12 2023 - 12:35:12 EST

Hi,

Am 12.10.23 um 16:05 schrieb Pavel Machek:
Hi!

There are however some known short comings:
- The sysfs leds interface does only allow to write one key at a time. The
controller however can only update row wise or the whole keyboard at once
(whole keyboard update is currently not implemented). This means that even
when you want to updated a whole row, the whole row is actually updated
once for each key. So you actually write up to 18x as much as would be
required.
- When you want to update the brightness of the whole keyboard you have to
write 126 sysfs entries, which inherently is somewhat slow, especially when
using a slider that is live updating the brightness.
- While the controller manages up to 126 leds, not all are actually
populated. However the unused are not grouped at the end but also in
between. To not have dead sysfs entries, this would require manual testing
for each implemented device to see which leds are used and some kind of
bitmap in the driver to sort out the unconnected ones.
- It is not communicated to userspace which led entry controls which key
exactly
Sooner or later, we'll need to support these keyboards.

But this has way too many shortcomings (and we'd be stuck with the
interface forever).
I had some thoughts on how the current userspace api could be expanded to
better reflect the capabilities of RGB keyboards. What would be required for
such an expansion to be considered?
You submit a proposal.

My quick writeup:

New sysfs entires:
- mode: single_zone_static, multi_zone_static, single_zone_breathing, multi_zone_breathing, single_zone_color_cycle, multi_zone_color_cycle, etc.
    - single_zone_static is mandatory, all other modes are optional (maybe even freely definable by the driver)
    - single_zone_static is the default and does not add any new sysfs entries that aren't already present on multicolor leds aka brightness, max_brightness, multi_index, mulit_intensity
    - multi_zone_static adds a new entry zones_count. mulit_intensity has now colors count * zones_count entries. aka a rgb keyboard with 126 leds would take 378 values for mulit_intensity
    - other modes are more device specific e.g.
        - multi_zone_breathing could have optional breathing_speed and max_breathing speed entries depending on whether or not the hardware supports it.
        - multi_zone_color_cycle could have a color_count and max_color_count entry. e.g. with color_count 2 you would then write 756 values to multi intensity, describing 2 states the driver should alternate between

Every multi_zone_* mode could also output a zones_image. That is a greyscale bitmap or even a svg containing the information where each zone is located and which outline it has. For the bitmap the information would be encoded in the grey value, aka 0 = zone 0 etc with 0xff = no zone (i.e. space between the keys). For the svg, the name of the paths would indicate the zone they are describing. Svg would have the advantage that it could be more easily used to also describe non square devices like mice or headsets that also might have complex RGB controllers.

This might already be doable with triggers? I'm unsure of triggers allow to change the length of multi_intensity however.

I'm in contact with the KDE folks. Plasma already has a keyboard brightness
slider, that soon
https://gitlab.freedesktop.org/upower/upower/-/merge_requests/203 will work
with multiple kbd_backlight. However the slowness of 126 sysfs entries makes
it a little bit janky still.

They are also thinking about expanding desktop accent colors to the keyboard
backlight when it supports RGB.

I have not reached out to the OpenRGB project yet, but is it alive and well
and under constant development: https://gitlab.com/CalcProgrammer1/OpenRGB.
Afaik it is currently a userspace only driver interacting directly with
hidraw mostly and has not yet implemented the sysfs leds interface.

Just listing this to show that there is definitely interest in this.
Yep, there's definitely interest.

These days, displays with weird shapes are common. Like rounded
corners and holes in them. Perhaps this should be better modelled as a
weird display?
I'm not sure if I can follow you here. Where would this be implemented? Also
I asume displays asume equal distance between pixels and that columns are
straight lines perpendicular to rows, which the key backlights have and are
not.
Yes, I know displays are a bit different from RGB LEDs. Gamma is
another issue. Yes, it is quite weird display. But 6x22 display may be
better approximation of keyboard than ... 126 unrelated files.

Or you could do 6x66 sparse display, I guess, to express the
shifts. But I believe 6x22 would be better.

It would go to drivers/auxdisplay, most probably.

Looking into it, thanks for the direction. But this would come with the downside that upowers kbd_brightness no longer controls the keyboard.

Another approach could be that i implement what i described under multi_zone_static above without the zones_count entry. Then there wouldn't be 126 unrelated files, but a multi_intensity that is describing multiple 3 subled leds. This would at least solve the performance problem and allow the shared brightness adjust the hardware supports to be implemented.


I checked
https://www.tuxedocomputers.com/en/Linux-Hardware/Zubehoer-USB-Co./USB-Zubehoer.tuxedo
, but you don't seem to have stand-alone keyboard with such RGB capability...?

No, it's for the integrated keyboards in some of our devices, this driver specifically is for the Stellaris line with optomechanical keyboards. The ite controller is internally connected, but is using the usb protocol.

https://www.tuxedocomputers.com/en/Linux-Hardware/Notebooks/15-16-inch/TUXEDO-Stellaris-15-Gen4.tuxedo

Kind regards,

Werner


Best regards,
Pavel