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. 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... > >>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. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
