On Mon, Sep 3, 2012 at 3:11 AM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > On Sun, 2012-09-02 at 22:47 +0200, Hans-J. Ullrich wrote: > [...] >> Just to explain: eeepc-wmi will not be fixed, as the developers told me (almost >> 2 years ago). The problem of this, is that the old hardware specs of my EEEPC >> 1005 HGO are not made available by the vendor. So it is of course impossible, >> to write a kernel module. >> >> All newer hardware, which is in most newer processors will be supported, of >> course! But as I said, my EEEPC 1005 HGO with the old single core cpu (Intel >> N280), still got the old and undocumentd API. >> >> > What steps exactly do you use to work around the bug? What do you >> > mean by "running the old kernel module"? Are you using an older >> > kernel? >> > >> >> No, I can choose either to load eeepc-wmi or use the option "acpi_osi="Linux" >> which let me load eeepc-laptop at startup. The second one I call the "old" >> module, as this is the old fancontroller module developed for my old cpu. >> >> If eeepc-laptop is used, then eeepc-wmi will not be loaded. > [...] > > Corentin, I assume you understand what's going on with these different > drivers. Shouldn't we add a dmi_enable_osi_linux quirk for the affected > models in drivers/acpi/blacklist.c? > > Ben. I think the wmi interface should be used when available, because it's the one asus is using on Windows. Fan control was kind of working using a methods that were probably not covered by Asus ACPI "ABI". So my point of view is "not supported by vendor on windows, hard to do with wmi: won't support it". Individuals can always boot with acpi_os=Linux if they want to, but I don't want to make that the default. Thanks -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
