Hi,
On 6/22/21 12:19 PM, Enrico Weigelt, metux IT consult wrote:
On 21.06.21 21:43, Hans de Goede wrote:
Hi,
quoted
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.
True.
Or am I missing something ?
In most cases the lacking way to associate the 2 is not a problem
because almost all systems have only a single keyboard backlight
and all existing standard Linux userspace code around kbd-backlights
(like upower) has been written with this assumption.
This is actually a problem when you plug in a fancy USB kbd with
backlight into a laptop where the laptop kbd also has a backlight ...
Fixing this would be great, but it requires fixes all over
the stack and associating the backlight with a specific kbd
is probably the smallest of the issues to solve here.
quoted
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
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:
So you have an input0 symlink under /dev/input to /sys/class/input/input0/
that is non standard, but that is not really relevant you get the same
output if you directly do:
ls -l /sys/class/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,
They are child devices of the input-device instantiated for the
keyboard device, the keyboard device itself is likely actually:
/sys/devices/platform/i8042/serio0
If you do "ls -l /sys/class/input/input0" then you will see
that this is a symlink pointing to
/sys/devices/platform/i8042/serio0/input/input0
The LED class devices for the kbd LEDs are instantiated
by the input-subsys itself, hence they use the input-device
as parent.
For HID based keyboards the HID device which is the parent
of the input-device will also be the parent of the kbd-backlight
LED class device since both are instantiated by the HID driver.
E.g. if I plug in a Logitech G510 keyboard I get this:
[hans@x1 ~]$ ls -l /sys/bus/hid/devices/0003:046D:C22D.000D/{leds,input}/
'/sys/bus/hid/devices/0003:046D:C22D.000D/input/':
total 0
drwxr-xr-x. 6 root root 0 Jun 22 12:32 input53
drwxr-xr-x. 6 root root 0 Jun 22 12:32 input54
'/sys/bus/hid/devices/0003:046D:C22D.000D/leds/':
total 0
drwxr-xr-x. 3 root root 0 Jun 22 12:32 g15::kbd_backlight
drwxr-xr-x. 3 root root 0 Jun 22 12:32 g15::macro_preset1
drwxr-xr-x. 3 root root 0 Jun 22 12:32 g15::macro_preset2
drwxr-xr-x. 3 root root 0 Jun 22 12:32 g15::macro_preset3
drwxr-xr-x. 3 root root 0 Jun 22 12:32 g15::macro_record
drwxr-xr-x. 3 root root 0 Jun 22 12:32 g15::power_on_backlight_val
So the input and LED class devices can already be associated
with each other by finding a common parent. This is not
unusual, this is e.g. also how video4linux tv-apps like
xawtv and tvtime find the alsa record/input device to get35 more lines