input devices vs. keyboard backlights [WAS: [PATCH v2] platform/x86: add support for Acer Predator LEDs]

On 21.06.21 21:43, Hans de Goede wrote:

Hi,

The LED API actually has specific features which are typically
only used with kbd-backlights, such as the brightness_hw_changed
attribute which was specifically added to allow userspace to
monitor when a laptops embedded controller changes the kbd-backlight
brightness in response to a Fn + somekey hotkey keypress, so that
userspace can show an on-screen-display notification that the
kbd brightness has changed (like how it typically does for
audio volume changes too) and also showing the new brightness
level. See: Documentation/ABI/testing/sysfs-class-led for
the docs for the /sys/class/leds/<led>/brightness_hw_changed

yes, that's great. but it seems we're still lacking a direct standard
way for associating an input device with the corresponding backlight
LED.

Or am I missing something ?

quoted

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

Just because you don't have a use for it does not mean that it
is not useful (and widely used) in cases where people use Linux
as a desktop OS, rather then for more embedded cases.

I'm actually using Linux on desktop for over 25 years now.

But let's go back to the kernel side.

quoted

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.

With USB-HID keyboards the LED class device will have the same HID-device
as parent as the input device. If there is no HID parent-device, then any
foo_kbd_backlight device will belong to the atkbd (PS/2) input-device.

Still a lot of if's and guessing :(

Why can't we make it appear the same way like the other leds (eg. caps-
lock) ?

Here's how it looks on my Portege:

| ~ ls -l /dev/input/input0:
|
| drwxr-xr-x 2 root root    0 Jun 22 11:42 capabilities
| lrwxrwxrwx 1 root root    0 Jun 22 11:42 device -> ../../../serio0
| drwxr-xr-x 3 root root    0 Jun 22 11:42 event0
| drwxr-xr-x 2 root root    0 Jun 22 11:42 id
| drwxr-xr-x 3 root root    0 Jun 22 11:37 input0::capslock
| drwxr-xr-x 3 root root    0 Jun 22 11:42 input0::numlock
| drwxr-xr-x 3 root root    0 Jun 22 11:42 input0::scrolllock
| -r--r--r-- 1 root root 4096 Jun 22 11:42 modalias
| -r--r--r-- 1 root root 4096 Jun 22 11:42 name
| -r--r--r-- 1 root root 4096 Jun 22 11:42 phys
| drwxr-xr-x 2 root root    0 Jun 22 11:42 power
| -r--r--r-- 1 root root 4096 Jun 22 11:42 properties
| lrwxrwxrwx 1 root root    0 Jun 22 11:42 subsystem ->
../../../../../../class/input
| -rw-r--r-- 1 root root 4096 Jun 22 11:42 uevent
| -r--r--r-- 1 root root 4096 Jun 22 11:42 uniq

I'd imagine also having some "input0::backlight" here.

These leds seem to be sub-devices of the keyboard device, that's perhaps
tricky to do with the current backlight drivers - but maybe just add
some symlink to it ?


--mtx

-- 
---
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@metux.net -- +49-151-27565287