On 11/24/2016 10:45 PM, Pali Rohár wrote:
On Thursday 24 November 2016 22:35:52 Jacek Anaszewski wrote:
I understood that we cannot notify about changes done by CPU
trigger due to high power usage... Or not?
Exactly.
So in this case exporting any new sysfs file (or using existing) which
report POLLPRI events for LED devices with active trigger is not
accepted.
Why so? The new feature would be made optional so existing users
wouldn't be affected, unless they enabled it in the kernel
config.
This means that trigger itself is problematic and trigger code should
tell to led subsystem if it should send POLLPRI events to userspace or
not. E.g. cpu trigger should tell led subsystem that events must not be
sent and e.g. rfkill trigger could tell that events can be sent...
It would entail changes in all triggers, I'd like to avoid for the
reasons I provided in one of the previous messages.
I've just looked one more time at POLLPRI description in poll(2)
documentation:
"There is urgent data to read (e.g., out-of-band data on TCP socket;
pseudoterminal master in packet mode has seen state change in slave)."
I don't think that brightness changes originating from triggers fall
into this category, whereas the ones originating from hardware do.
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.
That's why a separate read only file seems to be the only proper
solution. Moreover, the file should return the brightness from the time
of last POLLPRI.
--
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
