Hi!
> >> There might exist users that adjust LED brightness while having
> >> active trigger. The best example is default-on trigger - it sets
> >> brightness only on init, but remains active all the time. Whereas
> >> this could be fixed, there is another case: think of changing blinking
> >> brightness - it would be impossible.
> >
> > I don't see the breakage. For existing blinking and default-on
> > triggers, existing behaviour would be kept. Difference would be that
> > for hardware that changes triggers itself (like the keyboard light) we
> > would present it as a trigger. And you are right -- there would be
> > user visible changes there. You could not assign blinking, because
> > .. it already has a trigger. But I believe it is reasonable.
>
> We've already received negative feedback regarding blocking
> application of different trigger when hw brightness change
> notifications
Actually sometimes we'll get negative feedback for anything we do. I
still believe exposing the backlight case as a trigger is a right thing.
> are enabled. One solution to that is making the notifications
> orthogonal to the trigger mechanism. The other possibility is to allow
> for having more than one active trigger for a LED.
>
> We could think of defining a special type of persistent trigger that
> would be always enabled.
Yes, that could be done. I'd not call it persistent trigger, but
with right name...
#1:
Apparently some LEDs change themselves, and we can't find how or
when. That's thinkpad battery LED, for example.
#2:
Then there are some LEDs that change themselves, and we can get
notifications. We should make it very clear that we'll not send
notifications kernel did itself.
So... for #1 and #2 something like
led/hardware_changes_brightness
and for #2
led/poll_for_hardware_brightness_change
where poll() wakes the userspace up when the brightness changes, and
read() can get new brightness...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|