On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote: > Doesn't this option enable support for controlling the bay device via ibm_acpi? Yes, but the problem is that ACPI_BAY is not nearly good enough in ThinkPads... yet. > If so - if you compile this one, then the user who chooses to use bay.ko instead > to control the bay can not use ibm_acpi at all to control the remaining > functionality. I feel this should be dependent on ACPI_BAY=n. Please look at the patch I just sent. It allows ibm-acpi to load if ACPI_BAY is loaded. It will, of course, cause ACPI_BAY to refuse to load if ibm-acpi is already loaded, but that's probably fine as ACPI_BAY has just a single function. Note that these are all just stop-gap measures. We either need to have ACPI_BAY do everything needed in ThinkPads (like handling bay batteries), or to make both drivers work together, or I'll just pull all the ACPI_BAY functionality into ibm-acpi (and then I will definately conflict with ACPI_BAY). -- "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
