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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
