Hi,
On 19-10-16 15:59, Pali Rohár wrote:
On Wednesday 19 October 2016 15:33:54 Hans de Goede wrote:
+ itself and the driver can detect this. Changes done by
+ kernel triggers / software blinking and writing the brightness
+ file are not signalled.
Why? In case you have desktop application which show current brightness
level and you change manually it via echo something > /sys/ then that
application does not have any information about your change. And so it
show old value...
Well it seems like a bad idea to me to notify on changes caused by
triggers and blinking, even though those are visible under sysfs
if polling the brightness attribute. At which point it seemed to make
sense to only notify on changes done autonomously by the hardware,
rather then from any software (running on the main CPU).
As for specifically not notifying on write, the sysfs interface is root only,
so usually there will be a single daemon controlling the brightness,
and any users can go through that daemon and it can distribute change
messages itself (and will do so for the POLL_PRI events).
Since the usual use case is a single writing process, which is also
the same single process listening for POLL_PRI, it seems unnecessary
to me to notify the process about the write it has just done.
But if people think that we should consider multiple simultaneous
users (which seems like a bad idea to me, because of coordination
issues, but the API does allow it) and therefor should notify
of the brightness change on a write, I'm fine with doing a new
version implementing those semantics instead.
Either way notifying on brightness changes caused by triggers /
blinking seems like a bad idea to me.
Regards,
Hans
--
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
