On Thursday 23 February 2017 21:23:33 Pavel Machek wrote:
> Hi!
>
> > > 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.
Manual configuration is another option.
> > > 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,
Why? Because you prefer autoconfiguration and all other people must use
it only? Does not seems a good argument.
For machine which does not change, static policy file is enough too. And
for this simple case it will work correctly.
Why everybody must be forced to use some autoconfiguration and does not
allow user to use his own manual configuration?
> actually. See N900, there are 6 leds controlling one backlight.
I'm not saying that one script must be universal for everything. My
script is enough for machine with single keyboard led. And for other
people who have only one backlight keyboard it will work fine too.
For other cases something other could be written...
> > > 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.
But does not have to be. If your own scripts are under your control then
you can use it race-free.
> ("Hmm. I just
> wrote to the brightness file, and received poll notification. What is
> the current brightness?")
Value read *after* receiving poll notification. By poll notification we
know that brightness was changed. And to get new up-to-date value, new
read() must be done.
If value is changed again, you will receive another poll notification.
I do not see any race here. You will get poll notification about every
change, so what is the problem? You do not miss any change for sure.
> > > 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?
https://github.com/linrunner/TLP
http://linrunner.de/en/tlp/docs/tlp-configuration.html
> > > 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.
You are not forced to use something. I'm proposing extending current ABI
which can be used for processes who want those notification.
If you do not want it, just do not use it.
> 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.
Yes, somebody creates some right central daemon and everybody who want
to use LED kernel API will be forced to use that one "right" daemon?
And what happens if somebody write new daemon with new userspace ABI
just because that previous was incorrect/broken/does not fit all needs?
No kernel must not force which userspace application will be used for
some operation. This sounds like Microsoft product...
--
Pali Rohár
pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
