Hi,
On 01/24/2017 11:56 PM, Jacek Anaszewski wrote:
Hi,
On 01/24/2017 01:32 PM, Pavel Machek wrote:
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...?
Well, it is almost the same as hw_brightness_change I proposed
earlier. Persistent triggers OTOH would be more generic and it would
fit for the trigger approach Hans already implemented.
I have spend most of my time yesterday implementing the brightness_hw_changed
solution. I've just finished testing this on my XPS 15, so I'm going to post
the patches now. It would be nice if we can move forward with that as agreed
upon.
Regards,
Hans
