On Tue, 14 Jul 2009, Matthew Garrett wrote: > Certain hardware will send us events when the backlight brightness > changes. Add a function to update the value in the core, and > additionally send a uevent so that userspace can pop up appropriate > UI. The uevents are flagged depending on whether the update originated > in the kernel or from userspace, making it easier to only display UI > at the appropriate time. Ok. I have it working (event-based AND poll-based) in thinkpad-acpi, although it needs to be tested by dual-GPU, ACPI-based and OpRegion-based owners. Should the driver notify of *any* changes, even when the user is hitting the "ceiling" or the "floor" and the backlight value didn't really change? If the answer is no, shouldn't the backlight class filter these out itself, to guarantee a consistent experience? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
