tc1100 - The other WMI driver I maintain (the one that I’ve never even had the hardware for, let alone set eyes on, which always makes it ‘interesting’ to work on).

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.

It’s been a while, so:

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.

After re-reading an old readme & history file bundled with a different release of Launch manager (the one available for the Aspire 1690 - same version as the 5020 version, but this EXL806WW.BLD.txt file is missing from the 5020 release), I finally figured out that:

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).

WMI: Latest version (v7) was published on the ACPI mailing lists (I finally figured out my problems). This work has been ported to acer_acpi already (and not a moment too soon, since the Aspire 7520 has multiple PNP0C14 devices).

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.

Since some people apparently read this blog (for some unfathomable reason…), some more updates on progress in WMI-ACPI land.

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).