Eric Saxe wrote: > Ian Murdock wrote: > >> The buttons (disable/enable wireless etc.) don't seem to do anything. It depends on the notebook. On some machines, like the Ferrari 3400 and 4000, these buttons directly control devices (wireless, bluetooth radio, etc.) and work as expected without a driver hook into ACPI. >> Those just generate ACPI events, so presuming there's some way for a >> user-level process to monitor those events and dispatch the right action >> (e.g., bring the wireless interface down/up), that shouldn't be hard. On some machines, yes, these buttons do generate events in a machine-specific way. There's some device in the ACPI namespace that receives a Notify(), and we need a hook into ACPI to process the event. >> On Linux, there's a user-level daemon called acpid that does this. Not >> sure what the Solaris equivalent is, or even of the state of ACPI >> support. Yup, we're aware of acpid and the user-level processing of ACPI events in Linux.
The Solaris ACPI subsystem is based on Intel's ACPI CA interpreter; I integrated ACPI CA as a sub-project of the Boot Re-Architecture project (aka New Boot). Solaris Nevada is currently at the ACPI CA 20060721 release level (I'll be updating it later this year), and Solaris 10 is currently at 20060217 (and should be synchronized with Nevada in a future update). We debated a little how to best expose ACPI functionality to user space. My inclination was to avoid exposing ACPI-isms to user space when there was an existing Solaris framework to expose the functionality. This is based on the fact that ACPI is a means to an end, not an end unto itself. In fact, my focus as Solaris ACPI lead has been to provide an enabling framework to other projects; rather than a single "ACPI project" that attempts to boil the ocean, we have specific project teams that require ACPI support. The battery project recently integrated support for ACPI batteries using a relatively small kernel module that hooks into D-bus/HAL and the Gnome Power Manager. This was a case where the existing Solaris battery hooks were clearly insufficient. We discussed using Solaris sysevents to generically expose ACPI events, but there wasn't a clear use-case at the time. D-bus/HAL seems to mimic the sysevent framework. In either case, providing kernel modules to hook ACPI events and expose them, perhaps in an abstracted way, to user-level code is an area that need to be explored. I'd like to see use-cases from specific project teams, though; for example, the WiFi team may want to implement "interface on/off" via HAL. >> The hard part here is undoubtedly making sure the right codes >> for a variety of laptops are recognized, and that's something a larger >> user community can help us get right over time (that's how Ubuntu >> did it--very little of this worked at the beginning, but it improved). Certainly. Cheers, Dana
