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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ?

>> 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.

>> 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@xxxxxxxxx -- +49-151-27565287



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux