I can get limited control over the wifi by inserting or removing the eeepc_laptop module .... but I ragard this as dangerous as this effectively renders the fan control usless without the module (do not want to burn out my CPU).
Have not checked if the webcan also gets turned on ... but that's another probles as also the old uvcvideo driver no longer builds against 2.6.28.

This is a really bad situation for the eeepc 701 users as the ath5k driver is only working decently since 2.6.28 but also since this version the hotkeys have stopped working correcty.

I've a modified acpi event handler that reports (via logger) all unhandled acpi events but I get no evidence of any sort of acpi events on most hotkeys (only the suspend to ram and power off seem to work ... but those works even without eeepc_laptop anyway).
So it

This is a no-bug. The hotkeys are meant to generate ACPI events, which should be handled by acpid. The daemon acpid then needs to be configured to execute something at these key press. Thats probably your problem.

The eeepc_laptop module works on my EeePC 1000: all keys are generated correctly. Try it by running "acpi_listen" and pressing the keys. If it does not show any events, then it is not working.

I have read many messages about eeepc_laptop "not working correctly". It does correctly what it is supposed to do:
brightness is reported in /sys/class/backlight/eeepc/
rfkill switches are in /sys/class/rfkill/

/proc/acpi/asus is created by the "eeepc_acpi" module which was created by Asus (I think...) but has not been developed in-tree which is not a good thing. It is even "normal" that it wont build/work...

I have acpi handler configured to report all unhandled acpi events (read above) .... I'm getting no reports ... so on some keys there is no acpi event generated on 701 hardware.

So this is a bug !!!!! and the old eeepc_acpi did work correctly and I made a custom acpi handler to do some interesting things.

The "acpi_listen" thing you said .... do you mean pass that as option to module or to acpid ?

I have acpi handler configured to report all unhandled acpi events .... I'm getting no reports so on some keys there is no acpi event generated.

So this is a bug !!!!!

The "acpi_listen" thing you said .... do you mean pass that as option to module or to acpid ?

Regards
David Rao

--- Gio 22/1/09, bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org> ha scritto:

> Da: bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org>
> Oggetto: [Bug 12384] eeepc (701) hotkeys do not work correctly
> A: louigi600@yahoo.it
> Data: Gioved

No "acpi_listen" is a command you need to execute in a terminal.
However your acpid is configured, acpi_listen will pick up everything. So forget about acpid. The best way to isolate the problem is to not put acpid in between.

So run acpi_listen, press the hotkeys, and check what it reports.

If you press a key which does not generate an event (and which it should), then report back the exact key. Else, if acpi_listen reports something, then the problem lies with the configuration of acpid (probably /etc/acpi/handler.sh or something like that).

Ok ... I'll give it a go with acpid 1.0.8 but there are still 2 things that are wierd with post 2.6.28 kernels:
1) all acpi hotkeys (trough acpi events) worked fine till 2.6.28 (with acpid 1.0.4)
2) the /proc/acpi/asus directory dissapeared since 2.6.28 and hence the control to turn on and off wifi and webcam and this has nothing to do with acpid not intercepting hockeys acpi events

Well it's a little different to what I just said:

a)to be precise /proc/acpi/asus dissapears since the use of eeepc_laptop which became necessary since asus sourcecode derivee eeepc-acpi no longer compiles agains 2.6.28 or above

b)apparently the hotkesy were also working with older acpid 1.0.4 bit the scripts I was using failed because it was no longer able to get the current status (whether wifi or webcam were on or off) from /proc/acpi/asus/wlan and /proc/acpi/asus/camera respectively

c)the newer eeepc_laptop driver totally ignores whether the bios says that the wlan should be on or off (and possible this is also true for the webcam and any other device that bios says it can be turned off .... I've not checked yet).

By making some adgustments to the wifi toggle script I can get partial functionality ... turning off the wifi is only possible if you remove the eeepc_laptop module.

I've not yet sorted out the uvcvideo drive stuff ever since the old driver sources I had stopped compiling againt 2.6.28 so I can't say whether same trick used for wlan works with webcam. 

Ok I can now confirm that on the 701 the webcam does not work dew to the kernel not being able to turn the device on/off ... while the wlan gets turned on regardless of what bios says the webcam does not. maybe leaving it on from bios all the time might work around this....
The best solution would be to get back control over what should be on and what not. 

PS: what I just said also applies to 2.6.28.2 

I know there is some better hardware detection for the eeepc line in 2.6.29. For example, I need to get two patches from 2.6.29-rc2 to get proper rfkill support on the bluetooth and wifi. See here: http://code.google.com/p/acpi-eeepc-generic/wiki/Bluetooth This is on a 1000, not a 701, so YMMV.

The webcam should be able to run from the in-kernel uvcvideo driver. No need to compile something yourself.

I would suggest trying 2.6.29 release candidates, or even git, and report anything from there. Or just stick to what worked for you...

If you care to read the whole post: "dew to the kernel not being able to turn the device on/off" .... and yes I'm using the in-kernel uvcvideo driver and it does work if I turn it on all the time from bios.

Ok it's possible to turn on and off the wifi from /sys/class/rfkill/ ....
But there is still a few problems (at least on 701):
I've still not found any way to turn on and off the webcam,
By default when the eeepc_laptop module is loaded the status is on even if bios says it should be off,
Once the ath5k module is loaded even if you unload it before turning off the device (along also with pciehp and pci_hotplug) there is now way to get the wifi working again on subsequent turning on .... get this error:
     ath5k phy2: failed to wakeup the MAC Chip
     ath5k_pci 0000:01:00.0: PCI INT A disabled
     ath5k_pci: probe of 0000:01:00.0 failed with error -5

This is irrelevant to this bug report...

This is not a place to ask some help to make special keys execute commands or gather information in a wiki style.

You should look at your distribution forum/wiki/support.

So you are telling me that it's irrelevant that when eeepc_laptop module is loaded it ignores bios setting that wifi should be off and turns it on regardless ?

I undestand that the webcam on/off issue may be arguably an eeepc_laptop issue and that the athk5 issue is totally irrelevant .... but not the fact that the wifi hardware gets turned on by loading the eeepc_laptop module (regardless of bios setting).  

No, I mean "when eeepc_laptop module is loaded it ignores bios setting" is completely irrelevant to the bug report. Look at the title: "eeepc (701) hotkeys do not work correctly" Whats the connection between the bios setting not being used and the hotkeys "not working"?

If you want problems to be resolved, you need to open one bug report for each issue. You can't move off topic in each comments.

In all the post here, I found what should be around 8 different issues:
Comment #1 uvcvideo can't be built with 2.6.28
Comment #1 ath5k driver issues
Comment #2 no hotkeys acpi events
Comment #7 no hotkeys acpi events for kernel >2.6.28
Comment #7 Wifi and webcam control different on eeepc_laptop
Comment #8 eeepc_laptop ignores bios state
Comment #9 in-kernel uvcvideo can't control webcam state
Comment #13 ath5k can't be turned off then on
And the bug report summary means "eeepc_acpi doing things differently then eeepc_laptop"... That's a lot of off-topics post.


If the main issue is that the driver does not support all the features you want, that's something you can discuss on mailinglists/forums: it is still a work in progress. Bugzilla is not a place to dump comments about "it's not working". If you want help to set up everything, please look at your distribution, forums, mailing list and such.

Yea ... it's a mess  you're absolutely right.

Initially I did think that the acpi events were not even issued ... as messages were exchanged I found out that things were working in different ways but still there are some issues .... ok then we can regard this as closed and I'll start opening up an other report but only if you agree that it's a bug that eeepc_laptop is totally ignoring bios wifi setting ?

Hum... I don't know. I though the BIOS was the supreme master of the machine. If the BIOS turns off something, I though an OS  was not supposed to be able to turn it back on. I may be wrong.

But if the kernel can play with the settings while completely ignoring the BIOS, then yes I would consider it a bug. I think it might just be a matter of sane defaults for the eeepc_laptop. At initialization, values could be read from the BIOS, then applied accordingly.

So yes, go on and open another bug :) You can close this one (can you? or do we need admin to do so?)

Sorry if this is not correct since there is no code fix .... no non of the other cases fit any better:-(

Thats fine :)
If you open another one, could you post the link here so we can keep track?

The wifi being turned onn regardless of bios setting has moved to 12637
http://bugzilla.kernel.org/show_bug.cgi?id=12637