On Fri, 20 Jun 2008, Matthew Garrett wrote: > Various bits of hardware (some Thinkpads, for example) will execute ACPI > methods in response to events but won't generate any notifications. It > would be nice to be able to receive notifications on those updates in > order to avoid polling. How about something like the following? No comment on the code itself, but I have some about the whole idea. If I missed the point, please explain it to me. Let me start pointing out that I am not really opposed to your idea, but I'd like to know if it is the best way to go about it, first. With such ACPI notifies, you could have HAL do some of the stuff kernel drivers are doing. So far so good (well, sort of). But that is NOT necessarily the best, or even the correct way to do it. You could use ACPI "traps" sending events to userspace to know brightness changed, but the proper way to have those events would be for the backlight class to send uevents for such stuff, instead. Remember that if ACPI core sends too much data to userspace directly, we can't easily fix stuff in the drivers to present a more or less sanitized view of things to userspace. So I'd really like to know what you need it for? What sort of hardware events you'd like to be notified that thinkpad-acpi is not notifying you about, for example? Avoiding polling is ALWAYS a good thing. But being careful about what you export to userspace is ALWAYS wise as well. I believe we can do both. Even if it means we need to go around fixing half-completed sysfs classes until they're good enough an API for us and userspace. rfkill is a prime example of the effort that might be needed. -- "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
