On 16.06.21 19:50, Hans de Goede wrote: Hi, >> hmm, keyboard backlight ... don't we already have something for that >> in input subsys ? I believe that some lone LEDs aren't the right subsys >> for those stuff. > > Actually the standardized userspace API for exporting keyboard backlights > is using the LED class sysfs API, e.g.: > > cat /sys/class/leds/tpacpi\:\:kbd_backlight/brightnes Sounds like we don't have an API for that particular case at all. Everbody just exposes LED class devices and userland always needs hardware specific code to practically use it. We should at least have some standard mechanism for get least getting the connection between an input device and it's backlight device(s). > And the same for Dell and other kbd backlights, also the upower > daemon even has code for dealing with kbd-backlights: > https://gitlab.freedesktop.org/upower/upower/-/blob/master/src/up-kbd-backlight.c > exporting them over its dbus API so that non-root users can > control them. Looks like a very complicated way to do that. But actually I've never understood why I should use this strange upower thing anways :p > Basically using the LED class for kbd-backlight functionality > basically is the defacto standard under Linux, so exposing this > through the LED class is definitely the right thing to do. In general, LED class isn't so bad, as it already gives us LED control (*1), but I don't see any portable way for finding the corresponding LED for some input device. In DRM I see the backlight as subdevice. --mtx *1) just recognized that on my toshiba portege (TOS6208) it only works for readout - writing to "brightness" does nothing at all -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
