xorg.conf is dead - long live xorg.conf

For a UK layout keyboard, stick the following in /etc/hal/fdi/policy/10-keymap.fdi (for other layouts, change gb and/ or add as appropriate).

This is just enough to merge with the existing file & blat the keyboard layout (without having to resort to re-implementing the default Slackware FDI).

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.layout" type="string">gb</merge>
    </match>
  </device>
</deviceinfo>

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.

I’ve been experimenting now for the last few months with adding rfkill support to acer-wmi in my (rather limited these days) free time (the short, short version of ‘why’ is that this will allow the wireless & bluetooth buttons to just work out of the box on those laptops which have them properly mapped by HAL[1]).

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

I’ve been rather quiet lately, so time for the latest news:

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.

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

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

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.

I’ve been poking around the ‘newer’ AMW0 DSDT implementation (I’ll call it AMW0 v2), and I think I’ve worked it out now. Basically, rather than being an extension of the old AMW0 (we’ll name this ‘AMW0 v1′ to be original), it’s actually a backwards compatible addition of WMID to AMW0 - it has all the methods from both (plus an extra method to return a binary MOF), so can be treated as either.

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

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