From: Pavel Machek <pavel@ucw.cz>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jacek Anaszewski <j.anaszewski@samsung.com>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Tony Lindgren <tony@atomide.com>,
linux-leds@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Darren Hart <dvhart@infradead.org>
Subject: Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109
Date: Tue, 15 Nov 2016 12:48:59 +0100 [thread overview]
Message-ID: <20161115114859.GA7018@amd> (raw)
In-Reply-To: <128aae59-b790-42f1-7d66-81391c9330c3@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
Hi!
> >>>The LED you are talking about _has_ a trigger, implemented in
> >>>hardware. That trigger can change LED brightness behind kernel's (and
> >>>userspace's) back. Don't pretend the trigger does not exist, it does.
> >>>
> >>>And when you do that, you'll have nice place to report changes to
> >>>userspace -- trigger can now export that information, and offer poll()
> >>>interface.
> >>
> >>Well, that sounds interesting. It is logically justifiable.
> >
> >Thanks.
> >
> >>I initially proposed exactly this solution, with recently
> >>added userspace LED being a trigger listener. It seems a bit
> >>awkward though. How would you listen to the trigger events?
> >
> >Trigger exposes a file in sysfs, with poll() working on that file
>
> Hmm, a new file would give the advantage of making it easy for
> userspace to see if the trigger is poll-able, this is likely
> better then my own proposal I just send.
Good.
> >(and
> >probably read exposing the current brightness).
>
> If we do this, can we please make it mirror brightness, iow
> also make it writable, that will make it easier for userspace
> to deal with it. We can simply re-use the existing show / store
> methods for brightness for this.
Actually, echo 0 > brightness disables the trigger, IIRC. I'd avoid
that here, you want to be able to turn off the backlight but still
keep the trigger (and be notified of future changes).
> I suggest we call it:
>
> trigger_brightness
>
> And only register it when a poll-able trigger is present.
I'd call it 'current_brightness', but that's no big deal. Yes, only
registering it for poll-able triggers makes sense.
> >Key difference is that only triggers where this makes sense (keyboard
> >backlight) expose it and carry the overhead. CPU trigger would
> >definitely not do this.
>
> Ack only having some triggers pollable is important.
Thanks,
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 --]
next prev parent reply other threads:[~2016-11-15 11:48 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 19:23 PM regression with LED changes in next-20161109 Tony Lindgren
2016-11-09 20:45 ` Jacek Anaszewski
2016-11-10 8:49 ` Hans de Goede
2016-11-10 12:56 ` Jacek Anaszewski
2016-11-10 13:04 ` Hans de Goede
2016-11-10 13:55 ` Jacek Anaszewski
2016-11-10 16:36 ` Pavel Machek
2016-11-10 16:29 ` Pavel Machek
2016-11-10 16:44 ` Hans de Goede
2016-11-10 20:48 ` Pavel Machek
2016-11-11 8:25 ` Hans de Goede
2016-11-10 17:55 ` Tony Lindgren
2016-11-10 20:29 ` Pavel Machek
2016-11-10 21:34 ` Jacek Anaszewski
2016-11-11 12:01 ` Pavel Machek
2016-11-11 17:03 ` Jacek Anaszewski
2016-11-11 19:28 ` Hans de Goede
2016-11-11 22:12 ` Pavel Machek
2016-11-12 8:03 ` Hans de Goede
2016-11-13 9:10 ` Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109) Pavel Machek
2016-11-13 9:44 ` Hans de Goede
2016-11-13 20:45 ` Pavel Machek
2016-11-12 10:24 ` PM regression with LED changes in next-20161109 Jacek Anaszewski
2016-11-12 10:33 ` Hans de Goede
2016-11-12 19:14 ` Jacek Anaszewski
2016-11-12 21:14 ` Hans de Goede
2016-11-13 11:44 ` Jacek Anaszewski
2016-11-13 13:52 ` Hans de Goede
2016-11-14 9:12 ` Jacek Anaszewski
2016-11-14 12:51 ` Hans de Goede
2016-11-15 10:01 ` Jacek Anaszewski
2016-11-15 10:09 ` Hans de Goede
2016-11-15 10:31 ` LEDs that change brightness "itself" -- that's a trigger. " Pavel Machek
2016-11-15 10:58 ` Jacek Anaszewski
2016-11-15 11:11 ` Pavel Machek
2016-11-15 11:21 ` Hans de Goede
2016-11-15 11:48 ` Pavel Machek [this message]
2016-11-15 12:06 ` Hans de Goede
2016-11-15 12:11 ` Pavel Machek
2016-11-15 13:28 ` Jacek Anaszewski
2016-11-15 13:48 ` Hans de Goede
2016-11-15 14:04 ` Jacek Anaszewski
2016-11-15 14:30 ` Hans de Goede
2016-11-15 14:41 ` Jacek Anaszewski
2016-11-17 22:12 ` Hans de Goede
2016-11-15 11:17 ` Hans de Goede
2016-11-14 8:31 ` Pavel Machek
2016-11-11 22:06 ` Pavel Machek
2016-11-10 8:34 ` Hans de Goede
2016-11-10 15:11 ` Tony Lindgren
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=20161115114859.GA7018@amd \
--to=pavel@ucw.cz \
--cc=dvhart@infradead.org \
--cc=hdegoede@redhat.com \
--cc=j.anaszewski@samsung.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/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).