On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote: > > It should work with the generic bay device too, but I have no ideas about > > dock. But you'll need to deal with udev with the new bay device, something > > I am not too happy about. These things are ACPI events, they should remain > > so unless all other ACPI events are going to become uevents. > > So ACPI is just a mechanism - an implementation detail in the kernel. I > don't think we should have special ACPI events to deal with bay/dock activity. Well, that's how the userspace power management structure operates right now. We can walk away from that, of course, but if we are going to, then let's do it for the entire set of ACPI events sent to userspace. In the meanwhile, I would really appreciate a way to hook ibm-acpi into bay so that I can provide the ACPI events ibm-acpi used to generate... we can deprecate them and remove them in one year's time, or when the /proc/acpi/events (and its sysfs counterpart) interface gets removed, whichever happens first. > If for whatever reason we ever dock something without using ACPI, we can > make this transparent to userspace. Yes. But this is also true for battery, thermal notifications, suspend/resume, and pretty much every ACPI event :-) -- "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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
