linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
	Darren Hart <dvhart@infradead.org>,
	platform-driver-x86@vger.kernel.org
Subject: Re: LED devices & poll() for brightness attribute
Date: Thu, 23 Feb 2017 21:23:33 +0100	[thread overview]
Message-ID: <20170223202333.GA19376@amd> (raw)
In-Reply-To: <20170223144852.GD24201@pali>

[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]

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. 

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

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-02-23 20:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22  9:06 LED devices & poll() for brightness attribute Pali Rohár
2017-02-22 12:25 ` Pavel Machek
2017-02-22 12:39   ` Pali Rohár
2017-02-22 20:54     ` Pavel Machek
2017-02-22 21:16       ` Pali Rohár
2017-02-23 14:37         ` Pavel Machek
2017-02-23 14:48           ` Pali Rohár
2017-02-23 20:23             ` Pavel Machek [this message]
2017-02-23 20:44               ` Pali Rohár
2017-02-23 21:03                 ` Pavel Machek
2017-02-24  8:50                   ` Pali Rohár
2017-02-24  8:52                     ` Hans de Goede
2017-02-24  8:58                       ` Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170223202333.GA19376@amd \
    --to=pavel@ucw.cz \
    --cc=dvhart@infradead.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).