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 ------------------------------------------------------------------------------ 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
