On 11/25/2016 12:05 PM, 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.
And that is a _good_ thing. We don't want to deal with "echo heartbeat
kbd_backlight_trigger" and then asking for hardware brightness
changes.
I was far from proposing multi-trigger solution here.
Just wanted to highlight that with trigger approach there is
a trade-off problem.
Lets keep it simple. Yes, monitoring backlight state while hardware
updates it is useful. But doing the monitor when some kind of blinking
from the kernel is active is just a unneccessary complexity...
Triggers are not limited to periodic blinking or reporting cpu
activity. There is also oneshot trigger that can be used e.g. when
user touches the screen, as Pali mentioned.
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.
Well.. actually... I think this is a little bit over complex and
probably unneccessary. I'd let Hans implement whatever he thinks is
easiest.
I'd say this is the trigger approach which is a bit convoluted.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
