Hi! > > So... you don't want to use systemd, so don't use systemd. What is > > the problem? :-) > > > > > And my own application for controlling leds should know current > > > state of them if it is possible. > > > > If you have at most one application controlling each LED, you are > > fine. That's quite common situation, serial port can also be opened > > at most once. Do you actually have two applications accessing one > > led? If so, what applications? > > First application which controls leds is integrated into desktop > environment. In basic/default settings it do nothing automatically, just > show GUI bar to user and allow user to adjust LED level. Ok. Desktop wants to control the backlight, because it makes sense to turn it off when the screen is blanked, and dim it when screen is dimmed. Situation is quite similar to display backlight, actually. > Second one is basic shell script executed at specific situation (e.g. > power adapter was unplugged) which changes LED level. Ok, and this is where the problems start. You are not supposed to control keyboard backlight like that. (In the same way you can't control display backlight like that.) There are numerous problems with the shell script: 1) how to identify the keyboard backlight LED 2) there may be more then one 3) synchronization problems 4) need to be root Your shell script should talk to the desktop, because it already knows where the backlight is, and the problems disappear. > > Yes, we _could_ do that. Would be slightly confusing > > w.r.t. triggers. But is it good idea? > > Above situation for setting manual level of led is normal. And in this > situation setting trigger or blink support does not make sense. > Specially when user want to manually set led level. > > I think it is good idea to provide some poll-able sysfs for this change. > And if brightness is used for writing, then I would expect that > brightness also provide poll() state. > > Yes, it could be little confusing due to triggers/blinking support, but > I think it is better as providing new sysfs file and it does not make > this interface worse... I believe the confusion is not worth it. Talk to the desktop people, there should be good way to control the backlight without reaching lowlevel interfaces directly. > > And yes, with three color LEDs, userspace daemon managing LED state > > will be pretty much mandatory... > > Why it should be running daemon? Script which you start when you want > change is also enough... no need to have permanently running process. Because you want to play multiple patterns on the LED. You probably also want to automatically control the keyboard backlight LEDs using ambient light sensor. Shell should not be involved. This is one example of automatic backlight / keyboard backlight / LED patterns. And yes, this should be integrated with desktop, not using /sys/class/leds directly. https://gitlab.com/tui/tui/blob/master/ofone/mond Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
