lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 23 Feb 2017 21:23:33 +0100
From:   Pavel Machek <>
To:     Pali Rohár <>
Cc:     Richard Purdie <>,
        Jacek Anaszewski <>,,,
        Darren Hart <>,
Subject: Re: LED devices & poll() for brightness attribute


> > 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
> Exactly same as it is doing desktop. It is possible to 100% reimplement
> desktop logic for identification of keyboard backlight LED

Exactly! If you are reimplementing logic from another project, it is
strong hint that you are doing something wrong. 

> > 2) there may be more then one
> Yes and script can be adjusted to use specific one (config option for
> script).

No, you should autoconfigure it, actually. See N900, there are 6 leds
controlling one backlight.

> > 3) synchronization problems
> This is reason why poll() is needed. So desktop GUI will receive
> information that somebody else changed LED.

Actually, poll will not help you. If both your script and desktop
access the LED at the same time, there will be races. ("Hmm. I just
wrote to the brightness file, and received poll notification. What is
the current brightness?")

> > Your shell script should talk to the desktop, because it already knows
> > where the backlight is, and the problems disappear.
> Sometime there does not have to be any desktop loaded. It could but it
> does not have to be.
> Look at TLP scripts. They are very popular, and they have no

Do you have a link?

> > 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 probably every desktop will use own different method like before. No
> thanks. I do not want to depend on particular desktop or implement
> zillions of different desktop APIs. And even depend on desktop.

And I don't want led/brightness file to be used for interprocess
communication. I especially don't want to deal with _6_ keyboard led
files to be used for interprocess communication -- what is desktop
expected to do when you set different brightnesses to each of them?

You don't want to deal with desktop API, yet expect all the desktops
to follow your prefferred API (poll on led/brightness?).

There should be one component controlling the keyboard backlight. Your
scripts should talk to that component.

(cesky, pictures)

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists