Asus Wireless button not updating WLED

[Filippo Carletti]

Binary package hint: acpi-support

Ubuntu 9.10 beta, updated.
acpi-support 0.127

When I press the wireless button on my Asus V6V laptop, wireless lan is disabled (radio off), but the wireless led remains switched on.

Changing the last line of /usr/share/acpi-support/state-funcs, substituting dash with underscore make the led work as expected, switching on and off at every button press, reflecting radio state.

- test -w /sys/devices/platform/asus-laptop/wlan && echo -n "$action" > /sys/devices/platform/asus-laptop/wlan
+ test -w /sys/devices/platform/asus_laptop/wlan && echo -n "$action" > /sys/devices/platform/asus_laptop/wlan

[Steve Langasek (vorlon)]

Thank you for taking the time to report this issue and help to improve Ubuntu.

I'm hesitant to make this change such a short time before release, because of the various reports from people that the setLEDAsusWireless function breaks things for them when it's active (bug #293943, bug #334368). Ultimately this LED switching *should* be handled in the kernel, not in acpi-support; and it seems that for at least some models this is already the case, so I'm concerned that "fixing" this script will introduce a regression.

[Filippo Carletti (filippo-carletti)]

I read those bug reports before filing this and I agree with you on potential regression problems.

Kernel 2.6.31 introduced a small change in asus-laptop.c:
#define ASUS_HOTK_FILE KBUILD_MODNAME
instead of
#define ASUS_HOTK_FILE "asus-laptop"

So, now, all asus-laptop specific settings live in
/sys/*/asus_laptop
instead of
/sys/*/asus-laptop

While I agree that the kernel should handle led, I don't see why a script should reference a non existing path.

[Steve Langasek (vorlon)]

Oh, the script clearly shouldn't reference a non-existent path. The question is, what's the right way to fix it - by fixing the path, or by dropping the script?

We know that it's wrong - a kernel bug - if the script is needed at all. We also know that the last time the script was functional, it broke things for users on a number of models. What we don't know is how many users the LED is already working for, how many this change will fix it for, and how many it will break it for.

Perhaps we should reassign this bug to the kernel, so the LED interaction can be fixed there?

[Filippo Carletti (filippo-carletti)]

The script could easily be fixed after release.
Let's reassign to kernel, for now.

[Donatas Glodenis (dgvirtual)]

so, what are the outcomes of this bug report?

As for me, my notebook Asus A8F running Kubuntu 9.10 is also affected. I also noticed that, besides the need to correct the end of file /usr/share/acpi-support/state-funcs , the /etc/acpi/events scripts have wrong acpi event in my case, so I had to create a new file there and put this in it a corrected keycode 0000005d instead of the 0000005e or 0000005f:

cat /etc/acpi/events/asus-wireless
event=hotkey (ATKD|HOTK) 0000005d
action=/etc/acpi/asus-wireless.sh

and then the abovementioned script changes the led status correctly (but, as noted, it does not handle the toggling of the wireless itself, which is a kernel function now).

But, although this workaround solves the button-induced wireless toggle reflection by led problem, it does not correct the problem when the toggle is done using software, in my case, the knetworkmanager applet. The wireless gets disabled, but the led does not know about that.

Any workaround for that problem?

On another note, how do we help the kernel asus-laptop module developers solve the problem?

I don't see that this bug were forwarded upstream...

[Donatas Glodenis (dgvirtual)]

I reported this (or mine, in particular) problem to the kernel bugtracker: http://bugzilla.kernel.org/show_bug.cgi?id=14576

[Steve Langasek (vorlon)]

> But, although this workaround solves the button-induced wireless toggle
> reflection by led problem, it does not correct the problem when the
> toggle is done using software, in my case, the knetworkmanager applet.
> The wireless gets disabled, but the led does not know about that.

> Any workaround for that problem?

No - this is another reason why the LED handling needs to be done inside the kernel in connection with the rfkill interface, and not handled via an acpi-support script.

[Filippo Carletti (filippo-carletti)]

After update to 9.10 final the wlan button doesn't switch off the radio. The only way to disable wireless I found is to unload the ipw2200 module. There's no point in changing the led status if it doesn't reflect the radio status.

[Filippo Carletti (filippo-carletti)]

Update:
echo 1 >/sys/bus/pci/drivers/ipw2200/0000\:03\:02.0/rf_kill
switches off the radio.
But /sys/bus/pci/drivers/ipw2200/0000\:03\:02.0/led seems to be ignored.

[Filippo Carletti (filippo-carletti)]

Reference bug opened upstream:
http://dev.iksaif.net/issues/14

Now, I'm using acpi, all Asus V6V buttons work as expected.

[Steve Langasek (vorlon)]

reassigning to the kernel, as discussed.

[Archish (archish)]

The same issue exists with ASUS K40IN model. The wifi switch LED does not power off when WIFI is disabled using the function key. The issue also exists with Kernel 2.6.32.5.

[Dehumanizer (rudolf-hellmuth)]

the same with asus K50IN. LED does not power off.

[MF (mmuruev)]

In asus A6Vm Wi-Fi led off, after back from hibernate/suspend mode. Wi-Fi card work normal.

[John Doe (jodo-deactivatedaccount)]

Same Problem with an Asus V6V on Maverick here.

[Donatas Glodenis (dgvirtual)]

Same problem still exists on Asus A8F in Natty. I still have to fix/add the scripts

/etc/acpi/events/asus-wireless
==============
event=hotkey (ATKD|HOTK) 0000005d
 action=/etc/acpi/asus-wireless.sh
==============

/etc/acpi/asus-wireless.sh
==============
#!/bin/sh
# Find and toggle wireless devices on Asus laptops

test -f /usr/share/acpi-support/state-funcs || exit 0

. /usr/share/acpi-support/state-funcs

toggleAllWirelessStates;

# Update the Asus LED to reflect the new status of the wireless
! isAnyWirelessPoweredOn;
setLEDAsusWireless $?
==============

and even add the section to file
/usr/share/acpi-support/state-funcs
at the very end of it:

==============
# Pass '1' to light LED and '0' to dark LED – added back in by donatas
setLEDAsusWireless()
{
    action=`test "$1" -ne 0 && echo 1 || echo 0`

    # (Older) asus-acpi module
    test -w /proc/acpi/asus/wled && echo -n "$action" > /proc/acpi/asus/wled

    # (Newer) asus-laptop module
    test -w /sys/devices/platform/asus_laptop/wlan && echo -n "$action" > /sys/devices/platform/asus_laptop/wlan
}
==============

which was previously present in this file (in Karmic perhaps) but removed since.

[Donatas Glodenis (dgvirtual)]

Same problem still exists on Asus A8F in Precise.

Here are the reference bug reports upstream, both of which are closed without fixing.

It appears that there is no way to control the wireless led apart from acpi scripts in some models of Asus laptops.

So please do fix the acpi scripts, so they control the toggle.

[Donatas Glodenis (dgvirtual)]

Sorry, did not paste the reference bug report links:
https://bugzilla.kernel.org/show_bug.cgi?id=14576
http://dev.iksaif.net/issues/14

[penalvch (penalvch)]

Filippo Carletti, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Filippo Carletti (filippo-carletti)]

Unfortunately I no longer have the Asus notebook, I can't test current version.

[penalvch (penalvch)]

Filippo Carletti, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/451108/comments/20 regarding you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.