Hi! > >>As pointed in other email, we do not know if HW really controls keyboard backlight, > >>so adding "fake" trigger on machines without HW control is not a good idea. > > > >Well, if we know that hardware will not change the brightness on its > >own, yes, I'd avoid the trigger. If we don't know (as is common on > >ACPI machines, I'd keep the trigger). > > I'd drop the trigger approach due to the mess it can make in peoples' > minds due to the fact that LED class device handles trigger events > generated by itself. We can teach people. IMO the LED that changes itself is special, and trigger explains that nicely to the userspace. Plus, it allows us to keep this functionality out of the core. > I'd add a file hw_brightness_change or async_brightness or something > similar and make it only readable/pollable. current_brightness is > ambiguous and questionable. Well, exact name is not too important... 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
