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
signature.asc
Description: Digital signature
