On 11/25/2016 11:01 AM, Pavel Machek wrote:
Hi!
In view of the above we could report hw brightness changes with POLLPRI
on brightness file, but unfortunately we can't because it is impossible
to guarantee that readout of brightness file will return the brightness
the POLLPRI was meant to notify about.
Agreed here.
That's why a separate read only file seems to be the only proper
solution.
Yes please. And lets make self-changing leds into a trigger, as
proposed, and as Hans' patch should be already doing.
We can set one trigger at a time. In this case it will be impossible
to have hw brightness change notifications while other trigger is
active.
Moreover, the file should return the brightness from the time
of last POLLPRI.
Not sure I agree here. Normally, kernel returns current state for
variables, does not track "old" state.
It would report current state. The file called hw_brightness_change
should report last brightness change originating from hardware.
The most recent hw brightness change is still current state from
this perspective. It will be valid until next hw brightness change
occurs.
Current state does not mean current brightness in this case.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-leds" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
