Bug#649253: eeepc-wmi does not seem to adjust fan speed, but prevents use of fancontrol
On Mon, Sep 3, 2012 at 3:11 AM, Ben Hutchings <ben@decadent.org.uk> 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
Reply to: