change 'acerhk' to use 'autowlan=1' by default

Huh, acerhk is loaded in Edgy, that is great. I, however still need to pass some optionst through modprobe.d/options, namely
options acerhk autowlan=1
(and I need to revoke it in etc/modules - but it at least got installed).

still does not work out of the box on feisty.
two steps are still suffucient in order to get it working:
1) ad "options acerhk autowlan=1" (without the quotation marks) to /etc/modprobe.d/options
2) sudo modprobe acerhk
I would like to be helpful in identifying my laptop more closely, if you tell me I can post output of any file or command...

Hello Tomas, Could you paste the output of:

  cat /var/lib/acpi-support/*-*

so that we can identify your laptop.

Should this be done in the driver source, or on modutils; there seems to be little point putting the option in modutils when the driver could be fixed directly and this would avoid usespace having to handle things (which has advantages and disadvantages).

the driver is no longer actively developed, so that might be a problem to fix it
the output is this, I hope it helps, if you need anything else, just ask:

tom@bill:~$ cat /var/lib/acpi-support/*-*
R01-B1J

-1
tom@bill:~$

acerhk is still maintained at http://freshmeat.net/projects/acerhk/?branch_id=30497
current version is 0.5.35.

I've made a patch against 0.5.35 (attached) with better support for my laptop:
asaf@asaf-laptop:~$ cat /var/lib/acpi-support/*-*
R01-A1I
FUJITSU SIEMENS
AMILO A1650G
-1

I've also sent a mail to acerhk's maintainer to add my patch.
I can confirm that with my patch, autowlan=1 enables/disables the wireless led when the button is pushed.

I see, I changed the url to the homepage of the project in the bug description
I would like to provide similar patch, but I cant code - and I am not sure whether the info I provided is enough for identification, but other files in /var/lib/acpi-support/ are empty.
However, if onyone produces a patch, I will gladly test it (i can compile even if I cant code)

Still no progress as of the latest Beta

Still does not work in Feisty Release. I would be happy to somehow help to identify my laptop, I I only knew how, so that this could be fixed...

Still an issue for up-to-date Gutsy (installed just two days ago, so I report it so late after a release), so I change affected package to contemporary kernel image.

I still use the laptop (Prestigio 157) and will, if it does not crashes for several more years, so If you want to have a look at the bug, i will gladly test.

as of hardy alpha 3, the acerhk module is not even loaded anymore!

btw: I reflashed a bios several years ago, it was not bios specifically for Prestigio but for the same laptop but wth different OEM name, I do not know if it may have any impact on the fact that it is hard to identify this laptop

Just learned the development kernel is called just linux now, targeting at it (or should this be targeted at hotkey-setup?)

Hi Tomas,

Care to quickly confirm this is still an issue with the latest Hardy Alpha 6 release? http://www.ubuntu.com/testing

Mind the intrusion, but there is a newer version of acerhk (0.5.35 - as opposed to 0.5.34 in hardy), why wasn't it integrated to the kernel modules?

Leann Ogasawara> yep, still an issue.

Just to confirm hardy beta still has this issue on my travelmate 292.

On hardy heron beta, acerhk won't compile. Getting the following error message:
make[2]: *** No rule to make target `arch/x86/kernel/asm-offsets.c', needed by `arch/x86/kernel/asm-offsets.s'. Stop.
make[1]: *** [prepare0] Error 2

Mingxi: it is solved by removed the CFLAGS initialization (line 17 I think) from the Makefile

Hi damagedspline: I have removed the whole line (and also tried changing the CFLAGS to EXTRA_CFLAGS) but still get the same message. Any suggestions? Thanks!

mmmm... weird it compiles ok here after the removal of the CFLAGS line.

i even added it to an installation script which is intended for some fujitsu laptops...

relevant part of the script:
<code>
if [ ! -e acerhk-current.tgz ]; then
            if ! wget -q http://freshmeat.net/redir/acerhk/30497/url_tgz/acerhk-current.tgz; then
             printMessage "Error: Unable to download acerhk source code"
             exit 1
            fi
            printMessage "AcerHK source code downloaded successfully"
           fi
           tar xzf acerhk-current.tgz
           if ! cd acerhk-0.5.35; then
            printMessage "Error: Something wrong with downloaded AcerHK, try manual download of acerhk 0.5.35 and place it under /usr/src/fsca16xx/"
            exit 1
           fi
           #if ! wget -q http://fscamiloa16xx.googlecode.com/files/acerhk-0.5.35-FSC-AMILO_A16xx.patch; then
    # printMessage "Error: Unable to retrieve acerhk patch"
           #fi
           #printMessage "Patching AcerHK"
           #patch -i acerhk-0.5.35-FSC-AMILO_A16xx.patch acerhk.c
           printMessage "Installing required kernel module building tools - this may take a while..."
           if ! installPackagesIfNeeded build-essential linux-headers-generic ; then
            return 1
           fi
                                printMessage "Compiling AcerHK"
    if [ "Hardy" = $LINUX_VER ]; then
     #in kernel 2.6.24 - CFLAGS will fail the compilation
     grep -v "CFLAGS+=" Makefile > Makefile.fsc
     mv Makefile.fsc Makefile
    fi
           if make > ../compile.log ; then
           printMessage "Compile ended successfully!"
            mv acerhk.ko ../
            cd ..
           else
                                        cd ..
            printMessage "Error: AcerHK compile failed, compile log can be found at $(pwd)/compile.log"
           fi
</code>

Thanks for the info! I haven't find a solution yet, but I think it is due to some dependency/include problems. I tried copy the files it asks for to the linux header directory and it would keep asking for new files and ended up compiling almost the whole kernel....

the original bug still affects Hardy release

Mingxi:
I have made a few modifications to the acerhk makefile and now it compiles OK on several machines.
The diff is attached. Please let me know if its working for you two.

Mingxi:
I have made a few modifications to the acerhk makefile and now it compiles OK on several machines.
The diff is attached. Please let me know if its working for you too.

Hi!
Yes, with this patch and changing the CFLAGS to EXTRA_CFLAGS, it compiles without any problem on my machine. Thanks!!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

The new kernel does not change anything.

I just found out there is a driver that is included in the kernel and is maintained - it is called wistron_btns. I am trying to reach the author to include support for my laptop.

Hi, I'm trying to install this package and have done the things listed above (changed cflags to extra_cflags, changed line 40 according to the diff attached) and i still run into problems when running "make".

Here's the output i get when i run make:

matt@matt-laptop:~/Desktop/acerhk-0.5.35$ sudo make
make -C /lib/modules/`uname -r`/build SUBDIRS= M=/home/matt/Desktop/acerhk-0.5.35 V= modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.27-7-generic'
  CC [M] /home/matt/Desktop/acerhk-0.5.35/acerhk.o
/home/matt/Desktop/acerhk-0.5.35/acerhk.c: In function ‘call_bios_6xx’:
/home/matt/Desktop/acerhk-0.5.35/acerhk.c:582: error: bp cannot be used in asm here
make[2]: *** [/home/matt/Desktop/acerhk-0.5.35/acerhk.o] Error 1
make[1]: *** [_module_/home/matt/Desktop/acerhk-0.5.35] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.27-7-generic'
make: *** [acerhk.ko] Error 2

If anyone can shed any light on the problem that would be great.

Thanks.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Is anyone still affected by this issue? If so, have you tried the wistron_btns module? If trying the wistron_btns module have you tested the "force" module option?

On Hardy the acerhk module is in the linux-ubuntu-modules package, not the regular kernel packages.

Please report:

uname -a
lsb_release -a
modinfo wistron_btns
modinfo acerhk

Both acerhk and wistron_btns are only for 32-bit kernels since they make use of calls into the system BIOS - something that can't be done with a 64-bit kernel.

TJ: yes, I am affected. Trying wistron_btns with
sudo modprobe wistron_btns force=1 keymap=1557/MS2141
I get the buttons working (I checked in xev) and actions can be assigned to them, But the button to RF kill switch is not working. So basicaly, it works the same as acerhk without the modprobe options.

I tried to mail the author of the driver (wistron_btns), but he did not respond, I did not persuade it further.

information as requested:

Linux bill 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.10
Release: 8.10
Codename: intrepid

filename: /lib/modules/2.6.27-11-generic/kernel/drivers/input/misc/wistron_btns.ko
version: 0.3
license: GPL v2
description: Wistron laptop button driver
author: Miloslav Trmac <email address hidden>
srcversion: E23855711D2EEF4DF2706DE
depends: led-class,input-polldev
vermagic: 2.6.27-11-generic SMP mod_unload modversions 586
parm: force:Load even if computer is not in database (bool)
parm: keymap:Keymap name, if it can't be autodetected [generic, 1557/MS2141] (charp)

filename: /lib/modules/2.6.27-11-generic/kernel/ubuntu/misc/acerhk.ko
license: GPL
description: AcerHotkeys extra buttons keyboard driver
author: Olaf Tauber
srcversion: CF6DAC3715C5A289A62CE98
depends:
vermagic: 2.6.27-11-generic SMP mod_unload modversions 586
parm: poll:start polling timer (int)
parm: autowlan:automatic switching of wlan hardware (int)
parm: wlan_state:(assumed) initial state of WLAN LED/hardware (int)
parm: bluetooth_state:(assumed) initial state of Bluetooth LED/hardware (int)
parm: usedritek:enable dritek keyboard extension (int)
parm: verbose:output additional information (int)
parm: force_series:force laptop series, skip autodetection (uint)

Picking up from where we left off in bug #53310 "Wireless (ipw2200) does not work after waking up from sleep(without manually switching on).".

As your comments in bug #53310 points out, the acerhk module's "autowlan=1" is required.

Where I need further clarification is with:

1. When using acerhk autowlan=1 does this cause the radio frequency kill switch to be switched off (enabling the radio) when the PC resumes, or does it just enable the ability to press the physical switch to re-enable the radio?

If the latter then I think the solution is to add suspend/resume support to the acerhk module. suspend would do nothing but resume would simulate the kill switch set to 'off' if the switch-state was 'off' before suspend.

What might make this more complicated is if the switch is a momentary push-to-make type rather than a multi-position slider or locking push-to-make switch - can you tell me what kind of switch it is?

The acerhk driver should be modified by its maintainer to implement the rfkill API (see Documentation/rfkill.txt). With that implementation the power management (PM) system will ensure the device state is set correctly on resume.

1. The latter. Therefore autowlan=1 just enables the ability to manually pres the physical switch - it is not automatic.

As for the type of switch, I am not sure what you mean. I think it is unfortunately what you describe as momentary push-to-make type. There are no positions to the switch - it does not have "pressed" and "released" states. It works like a key on a keyboard - you press it, a key is written, and then you release it and it goes back to its original position. Only that wifi is turned off/on only after releasing the button whereas keys on keyboard work already after being pressed. (There is a picture of the laptop for you to check: http://www.gsm4u.cz/Obrazy/Prestigio_1570_20-rozlozeny_A4.jpg it is a similar type to the notebook in question. The button is the top one of the five buttons situated no the left.)

Acerhk is unfortunately no longer developed:-(.

(this bug has originally been opened because without autowlan=1, it is not possible to use one of the extra buttons to turn the wifi off and back on: without autowlan=1, the button that is supposed to manipulate wifi is treated just as another extra key, i.e. I can assign actions to it through GNOME, but I cannot turn off wifi with the button.
I think I am not the only one who is running linux on this laptop - I still regularly see exactly this type when I go to the library and I know that someone on our natinonal unix community is running BSD on it, so there must be some people running linux on it, this type was once rather popular in Czech Republic - just giving the rational that I may not the only one still affected.)

On Fri, 2009-03-20 at 17:41 +0000, TomasHnyk wrote:

> As for the type of switch, I am not sure what you mean. I think it is
> unfortunately what you describe as momentary push-to-make type.

Yes, that is correct. The key thing about this kind of switch is the
'state' has to be maintained in software and can therefore be
'forgotten' - which is what seems to be happening.

> Acerhk is unfortunately no longer developed:-(.

Maybe the acerhk users need to band together and see if they can invoke
some assistance in getting the driver cleaned up and added to the
mainline kernel. Once there it would not go stale.

> Maybe the acerhk users need to band together and see if they can invoke
> some assistance in getting the driver cleaned up and added to the
> mainline kernel. Once there it would not go stale.
That seems unlikely - there is wistron_btns already in the kernel already and it seems to handle most notebooks that also work with acerhk. I think kernel people do not like to have code that does the same thing in the kernel twice. I do not really know how to get my laptop supported in there - I tried to mail the author/maintainer of wistron_btns but he did not respond. I may re-email him, but then there is the problem that my laptop seems to produce no useful output to dmicode so it is impossible to recognize in software. Or should I mail someone else - I do not really know how these things work, kernel looks so scary...

With the creation of bug
https://bugs.launchpad.net/bugs/346586
I think this should be also closed as won't fix, since it cannot be fixed since the laptop is impossible to recognize (which is probably a hardware fault).