I’ve posted patches to add rfkill support to this driver to the linux-acpi mailing list. If you:

1) Have the hardware
2) Can compile your own kernel

Then please grab the patches, try them out and let me know if they work, or break horribly.

1) I’ve posted the final version of the patches to add rfkill support to acer-wmi on the 15th September to the ACPI mailing list.

_Hopefully_ these will go in for 2.6.28.

(This is only for wireless and bluetooth - still waiting for someone to use Linux on an Acer laptop that has built in 3G).

2) For now, rfkill is implemented by polling WMI every second to find the current state of the wireless and bluetooth devices. In future (at least, for WMID compatible laptops), it may be possible to switch this over to a WMI event based system, and avoid polling on those machines, but this will require extensive testing (especially on older machines, such as the Aspire 5040). I may get round to reposting my patch for this somewhere so the more adventurous among you can try it out and feed back.

3) From a button perspective, this will depend on how well rfkill-input is working these days (I haven’t tested lately). However, in HAL, all Acer laptops should be using the same basic keymap now, so we don’t need to keep patching for every single (near identical) laptop for KEY_WLAN and KEY_BLUETOOTH.

4) Unrelated aside to Acer Aspire One owners (so that this is documented somewhere) - it’s not supported by acer-wmi. It only provides a ‘dummy’ interface - the methods in the interface itself don’t actually do anything.

I may explicitly blacklist it in future so that people are aware of this.

Unfortunately, I’ve been hitting a few snags, most of which I’ve now been able to identify (but there are no solutions at present to all of them):

1) The mysterious double toggle:

Pressing either the wireless or the bluetooth button would trigger both to change states. I tracked this one down yesterday and the fix is pretty trivial.

2) rfkill-input not working until after being reloaded

rfkill-input won’t attach to an input device that doesn’t have KEY_WLAN. But KEY_WLAN isn’t added until HAL kicks in, which is much later. The ‘workaround’ to this is to build a modular rfkill-input, and then reload it after HAL has called setkeycodes. No proper solution yet for this one…

3) The KEY_WLAN cycle of doom

Unfortunately, some of the rfkill enabled wireless drivers send a KEY_WLAN when they detect that the device state has changed. So the following happens:

1) User presses KEY_WLAN
2) rfkill-input toggles all rfkill registered wireless radios
3) acer-wmi gets this signal, and changes the wireless radio state
4) Wireless driver detects the state change, and then helpfully sends a KEY_WLAN
5) Goto 2

And so on until I unload acer-wmi or the offending wireless driver. Consensus so far seems to be that wireless drivers should not using keypresses for event notification.

[1] I now have commit access to the hal-info repository, so I can get your keymaps added as soon as you send them to me

1) The input part of acer_acpi (the keyboard quirks) has been accepted by Dmitry Torokhov (the input subsystem maintainer) into his tree. This will be going into 2.6.25 - this means that if you have one of the laptops that requires the old acerhk keyboard quirk to make the extra scancodes work, you won’t need acer_acpi just for this fro 2.6.25 onwards. (This code is not acer_acpi specific, so I’ve never been happy with it just sitting in acer_acpi).

2) No news on any other upstream front I’m afraid - wmi & acer-wmi (the upstream port of acer_acpi) are _still_ waiting to be reviewed by the ACPI maintainer (not that I’m getting a little irritated now after three months…)

3) acer_acpi 0.11 will hopefully be released soon - I’ve not had any word of the device autodetection code breaking horribly. Quite the contrary, reports so far indicate that it’s working quite well, so it’s almost time to inflict^^^^^^release it.

4) There appears to be a bug with OpenSuSE 10.3 and the wmi-acer/ wmi module -

https://bugzilla.novell.com/show_bug.cgi?id=352648

I’m aware of it - but currently have no clue as to why it doesn’t work on OpenSuSE, yet works on the same hardware with other distributions.

1) It is actually possible to auto detect hardware on older Acer laptops
2) That I had originally misread this file, and that this can be done via ACPI-WMI

So, after ordering myself a firewire (aka ieee1394) cable, I’ve been able to play about with remote kernel debugging in Windows (unfortunately, forcing ACPI into step-by-step mode isn’t useful on a single machine, as it completely locks the machine and you need a remote one to force Windows to go to the next step. And the Windows kernel debugger can only do a remote connection via serial or firewire).

The result is that:

1) I can detect bluetooth on my Aspire 5020
2) I can take a good guess at how wireless detection works
3) I’m not sure on the Mail LED detection, but I do have some ideas.

Hopefully, this should be portable to the other older AMW0 type 1 laptops (and, fingers crossed, the non Acer laptops that also fall into this category). (In theory, based on Wistron’s comments in the driver, this method may well be portable to acerhk and wistron-btns, in the sense that the WMI interface on these laptops is just a front end for the old BIOS calls).

I wonder if people are trying to tell me something…?

acer-wmi: Initial RFC (request for comment aka first try, please review) has been posted to the ACPI mailing list. For WMID users, they will see no change. For AMW0 v1 users, the Aspire 5020 EC quirks are enabled by default (since all such laptops reported so far have the same quirk). The biggest change for is AMW0 v2 users, who have been switched over to the WMID methods.

I can’t do this in acer_acpi as I suspect, based on earlier reports, that there may be some upstream ACPI bugs we need to flush out to get this working properly, and I can’t backport ACPI bugfixes into acer_acpi.

So, for background - acerhk worked by making 32 bit BIOS calls. These calls take four arguments, each 4 bytes long, to give a total of 16 bytes.

AMW0 v1 just shifts the call into a method in WMI ACPI - we use the same arguments, but the call is done in ACPI, so we don’t have to care about poking into the BIOS, or whether this is a 32 or 64 bit system.

WMID implemented a ’simple’ method, so rather than needing to know the exact arguments for the BIOS, we just give the relevant method ID (and for writing, also the value), and then call that.

AMW0 v2 implements all the old AMW0 v1 methods, so is completely backwards compatible. However, since it also implements all of the WMID interface, it should be possible to update acer_acpi to use the WMID methods instead on these laptops, since it means we don’t need EC data for reading wireless and bluetooth (with the added advantage that we can control the mail LED through the ‘old’ AMW0 v1 methods).

Background:

I am currently trying to implement a mapping driver in Linux for WMI-ACPI (which is described here)

The short, short version for doing this is that unlike other laptop manufacturers, who define their own custom devices in ACPI-land and then talk to those directly, Acer uses WMI-ACPI, which is a proprietary standard defined by Microsoft. Unfortunately, Acer are not the only ones who use WMI-ACPI, so we cannot just assume that a WMI-ACPI device (PNP0C14 in ACPI & DSDT talk) is for Acer hardware and try to unilaterally claim it. Therefore, a generic driver needs to be written to handle WMI-ACPI (PNP0C14), and then acer_acpi can be rebuilt on top of this generic driver, instead of trying to talk directly to ACPI.

Current Progress:

So, to get to what you’re really interested in:

1) I did have a working WMI mapper (a lot of my early work can be found in the latest acer_acpi 0.10 RC releases).

2) However, the first round of comments pointed out that the WMI-ACPI specification calls for a full kernelspace to userspace mapper - so while I am not expected to (and probably won’t) write the userspace component, I did need to add another interface to the kernel part of the WMI-ACPI mapper to expose it to userspace (in this case, sysfs was recommended).

3) So I added a sysfs interface to expose WMI-ACPI to userspace. However, after releasing the latest versions with this (5, and 6 which just split WMI into two smaller, easier to review patches), I realised there were quite a few bugs & implicit assumptions in wmi.c:

i) wmi.c assumed there would only ever be one PNP0C14 device - according to the MS spec, this is not so - there can be many.

ii) wmi.c assumed a WMI method would always take input, and would execute a method then. Again, this is not true - rechecking the MOF’s I have for WMID Acer laptops, it’s clear that not all functions take an input.

iii) I also spotted a few cases of where I was needlessly re-inventing the wheel (as has been pointed out to other people in the past, and I keep learning - when you want to do something, there’s probably already a function in the kernel that does it).

So, although I have fixed most of these problems locally, I’ve broken the sysfs interface for the mapper with the changes required for (ii), and haven’t figured out how to fix it yet (hence the delay in publishing version 7 on the Linux ACPI mailing list). (And no, I don’t have a Git tree available with my changes - when the patches are ready for review, I’ll publish them to the mailing list. And quite frankly, at the moment they’re a mess again and need cleaning up regardless).

1) The generic WMI-to-ACPI mapping driver to go upstream will now be written by me.

My current work on this driver has already been integrated into the 0.10 RC releases - I will continue to backport my WMI work to acer_acpi (where possible and practical) until it gets accepted upstream.

2) The ‘upstream’ acer_acpi will likely be renamed acer-wmi, so as to:

i) Make it clear that acer_acpi is the out of tree version, and avoid any confusion with the in tree (acer-wmi) driver - as once acer-wmi is accepted upstream, development work will cease on the out-of-tree acer_acpi - I will maintain and bugfix it only for older kernels. The recommended path will be to upgrade to the latest stable kernel with acer-wmi (or nag your distribution to update their kernel).

iii) acer-wmi will now call the WMI driver (acer_acpi will call its own internal copy)

iv) The use of the -acpi name is being deprecated by the “next generation” of laptop drivers (sony-laptop, asus-laptop). Whilst I have considered the “acer-laptop” name, I feel it is inappropriate, since we are only driving the WMI based laptops, not all Acer laptops.

The acer_acpi name is also inappropriate, because as of 0.10 RC, acer_acpi is not really an ACPI driver anymore - it has bits of ACPI in it, but WMI is the “true” ACPI driver, whilst acer_acpi is now a platform driver[1] that just calls into WMI to do the ACPI bits for it.

(WMI has a defined ACPI interface device (PNP0C14) by Microsoft, so acer_acpi cannot claim the WMI-ACPI device for itself. Otherwise, if someone else wanted to write another Linux driver against WMI-ACPI, it would be a race between this driver and the other ones to claim PNP0C14. So instead, we will have just one WMI driver, which claims PNP0C14, and then other drivers just call into WMI to access the WMI-ACPI functionality.

(This is in contrast to other laptop vendors, who just define their own out-of-spec devices, so Linux drivers for them can claim these ACPI devices and drive them, since nothing else will).

3) The following from acer_acpi will _not_ be present in acer-wmi:

i) proc interface - PITA to maintain, and upstream will not accept new /proc interfaces for ACPI. The sysfs interface + subsystem integration is the future.

ii) Extra keys toggling - As per my discussions with the input subsystem maintainer, this belongs in i8042.c, not acer-wmi.

iii) Fan override - I’m not entirely comfortable submitting this straight away. I’d prefer to get acer-wmi in, then consider re-adding this later.

[1] A ‘platform’ driver, in the Linux kernel, to quote from Documentation/driver-model/platform.txt:

“This pseudo-bus is used to connect devices on busses with minimal infrastructure [..]; as opposed to large formally specified ones like PCI or USB.”