On Thu 15. Mar - 12:37:32, Kristen Carlson Accardi wrote: > On Thu, 15 Mar 2007 12:17:21 -0700 > Chris Wedgwood <cw@xxxxxxxx> wrote: > > > On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote: > > > > > This patch allows for ibm-acpi to coexist (with diminished > > > functionality) with other drivers like ACPI_BAY. > > > > Given the ACP_IBM_BAY implementation is more complete (or seems to be, > > please comment if that isn't the case) we should probably actually > > make sure that is the *preferred* code used (on suitable hardware) at > > run time surely? > > I haven't followed the ibm_acpi development lately, but when I first > wrote the bay driver, it had a couple features that ibm_acpi didn't have, > and then of course, is missing some it does have. What used to be the > case is that if bay was inserted after the laptop was booted, the ibm_acpi > driver would not capture the events because it would only install it's > notifier at driver load time on bay devices that existed. The second > case is that if you are using the generic dock driver (which is more > funtional than the ibm_acpi dock feature), for certain ibm laptops such > as the X60, you need to have undock events sent to the bay device so that > it can alert user space to unmount cd's etc (since the bay is on the ultrabase). But there's currently an issue with the second case you're talking about. The dock driver doesn't generate any event in the bay driver on undock. And due to the fact that the dock driver automatically issues a ACPI undock, the hardware indication on the dock station signals "everything alright" to the user so there's no way to tell the user that he is not allowed to pull away the docking station because there's still some file system mounted inside the cdrom. Userspace would need some time to handle that IMHO. Just a note, Holger > > > > > That way distributions can build both options and on IBM/Lenovo > > hardware it will use the IBM ACPI code and otherwise will use the > > generic ACPI BAY code? > > I think for now this is a good idea - the ibm_acpi solution should be > preferred over the generic bay driver till it is more fully developed. > I don't know how to ensure this is done wrt load order though. > > > > > Perhaps the IBM_ACPI_BAY code should go away and any missing > > functionality provided there should be merged into ACPI_BAY? > > > > I think this is a good idea. It would certainly be less confusing for users. > too late for this release though, perhaps this can be targetted at 2.6.22/23? > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ------------------------------------------------------------------------- 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
