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