New ACPI events handling script for all Asus EeePC

big_gie · 2009-01-21 17:56:55

I created a package which handles ACPI events from special function buttons on my Asus EeePC 1000. I inspired myself from many other packages. The result is a package which is generic: it should be possible to use it not only on the 1000 but on many other models. Actually it should work with the 700, 701, 900, 900A, 901, 904HD, S101, 1000, 1000H, 1000HD and 1000HE.

Features:
* Model agnostic
* Uses libnotify for OSD instead of the (IMO) crappy asusosd. See here for an (unrelated) example
* You can configure (in /etc/conf.d/acpi-eeepc-generic.conf) each of the button press to execute multiple commands (mute different channels for example) without changing the script (thanx to bash's arrays)
* Depends only on vanilla kernel features ("eeepc_laptop" and "rfkill" kernel module): no need to use a custom kernel
* Wifi On/Off/Toggle (with rt2860sta for now. Can be changed in /etc/conf.d/acpi-eeepc-generic.conf)
* Bluetooth toggle
* Suspend2ram on lid close and Fn+F1 (or any other events)
* Rotate screen (with xrandr)
* Toggle between different screen output (LCVDS, VGA, both-clone)
* Change resolution
Many more, see homepage

Homepage: http://code.google.com/p/acpi-eeepc-generic/
AUR: http://aur.archlinux.org/packages.php?ID=23318

Hapy EeePC!

Last edited by big_gie (2009-04-01 01:37:55)

chrispoole · 2009-01-26 16:37:34

I've tried it on my 1000H.

All works well --- 4 special buttons at the top, and the Fn key buttons.

My only issue now is that after I resume from suspend, my laptop-mode scripts in /etc/laptop-mode no longer seem to function.

I use laptop-mode to force the hard drive spindown times, otherwise I find the drive spinning down then immediately firing up again every 12s or so, causing a large load_cycle_count, dramatically shortening the hard drive's lifetime.

Any idea how I can find what command to use to make that script execute, so that I can add it to the commands in your acpi scripts?

big_gie · 2009-01-26 17:05:54

chrispoole wrote:

Any idea how I can find what command to use to make that script execute, so that I can add it to the commands in your acpi scripts?

Well if you want to know where to put this, I would say something like:

COMMANDS_SLEEP=(
    "xrandr --output LVDS --preferred --output VGA --off"
    "/etc/rc.d/logsbackup stop"
    "/etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh"
    "/your/laptop/mode/script.sh"
)

in the configuration file, around line 77. All commands in COMMANDS_SLEEP are executed when you press the sleep button. On my 1000 (and probably the 1000H too, as well as 900 and others...), it is Fn+F1. Each or the commands in the array will be executed one after the other. So here, xrandr will turn off external external monitor (I had trouble waking up when external monitor was on, should not affect if you dont have one attached), then it "stops" the rc script "logsbackup" which copies all you logs to /logsbackup (useful if your /var/log is mounted as ramfs), and finally execute the suspend2ram helper script "acpi-eeepc-generic-suspend2ram.sh" included. You could add at the end the script you want to be executed when you resume from suspend.

But if you want to know what script to execute... Then, hum, I don't really know. You're in the best position to know that yourself. I know that, on my other laptop, I use hdparm to reduce the power management of the drive to reduce the load_cycle_count in /etc/rc.local: "hdparm -B 254 /dev/sda" (or something similar, I don't have access to this machine now). So you could add a similar call to hdparm just after "...acpi-eeepc-generic-suspend2ram.sh" in the COMMANDS_SLEEP array. Or just simply re-start laptop-mode deamon with "/etc/rc.d/laptop-mode restart".

Note that by default, I configured my package to execute everything included in COMMANDS_SLEEP when you close the lid on battery (see COMMANDS_LID_CLOSE_ON_BATTERY, around line 114). So when you close the lid, it reacts the same as if you pressed Fn+F1 (sleep button).

I provide defaults in the package, but please feel free to modify it to your needs. This was a major reason to create the package. We need a way to configure what to execute on key press so that each user can have a completely different setup. Personally I use XFCE 4.6 svn but I hear some using KDE on there 1000. The 700 are less powerful then the 900/1000, so I can't put something dependant on KDE because users probably run something else.

My point is, the configuration file /etc/conf.d/acpi-eeepc-generic.conf should be simple enough to change to your own need. Don't be affraid to check it out! I even added an 20 second popup that needs to be disabled in the configuration file. I had too many reports of users saying it was not working but did not even checked the configuration file... At the end of the file, around line 130, just comment "EEEPC_CONF_DONE" or delete the line, to prove you read and configured the config file

There is a new version: 0.6.2-1. I'll upload to AUR in a sec.

chrispoole · 2009-01-27 22:09:28

Thanks, updated to latest version and added that line. Works well

Only other issue I've found is that turning off wifi then on again results in wicd not reconnecting to my wireless network.

It's unable to find any networks. Running 'ifconfig -a' shows ra0, but not connected to any IP address (I use dhclient as DHCP daemon).

I'm going to look into it a bit more tomorrow, to see if I can find a fix.

big_gie · 2009-01-28 03:22:58

In your configuration file, is it killing wicd and starting it again for toggling?
I was using this before yesterday:

COMMANDS_WIFI_POST_UP=("/etc/rc.d/wicd start" "/bin/su $XUSER --login -c \"wicd-client\"")
COMMANDS_WIFI_PRE_DOWN=("pkill wicd-client" "/etc/rc.d/wicd stop" "pkill wpa_supplicant" "pkill dhcpcd")

but removed it yesterday. If I disable wifi and enable it again, wicd seems to have problem reconnecting too.
So maybe just kill wicd and launch it back and uyou want wifi could correct the problem...

If not, you can always open an issue here:
http://code.google.com/p/acpi-eeepc-generic/issues/list

wimac · 2009-01-29 02:36:35

I can't get the volume keys fn-F7 fn-F8 and fn-F9 working on my 900 any ideas?

big_gie · 2009-01-29 02:45:46

Can you uncomment KEY_SHOW="1" in /etc/conf.d/acpi-eeepc-generic.conf, press the Fn+Fx keys and report the code of each key press?

Edit: The keycode should appear the same way as other OSDs. So if you use the default libnotify, you should see a window popup similar to this one: http://farm1.static.flickr.com/146/4062 … 1d541b.jpg (unrelated, but good example)

Last edited by big_gie (2009-01-29 02:47:49)

Yanaar · 2009-01-29 21:54:30

big_gie,

thank you very much for your package.

After a first try, where I could not toggle wifi, I decided to give it a second try

I own a 900A and this is what I did:

In acpi-eeepc-900A-events.conf I changed

KEY_Fn_F2=("00000010" "00000011")
to
KEY_Fn_F2="00000010"

because KEY_SHOW="1" reflects this (great thing this, by the way).

Therefore I changed

EEEPC_WIFI_TOGGLE=NONE
to
EEEPC_WIFI_TOGGLE=$KEY_Fn_F2

and commented EEEPC_WIFI_UP and EEEPC_WIFI_DOWN

because I didn't know what to do with it otherwise
In acpi-eeepc-generic.conf I changed WIFI_DRIVER to ath_pci, because I use the
madwifi-newhal-svn-driver with the stock kernel. I use wicd for network-connections.

Is this the right way?

Every key works as expected (did not test xrand though, is says "clone" for each press).

Yanaar

big_gie · 2009-01-29 22:05:04

Yanaar wrote:

big_gie,
thank you very much for your package.
After a first try, where I could not toggle wifi, I decided to give it a second try
I own a 900A and this is what I did:
In acpi-eeepc-900A-events.conf I changed
KEY_Fn_F2=("00000010" "00000011")
to
KEY_Fn_F2="00000010"
because KEY_SHOW="1" reflects this (great thing this, by the way).
Therefore I changed
EEEPC_WIFI_TOGGLE=NONE
to
EEEPC_WIFI_TOGGLE=$KEY_Fn_F2
and commented EEEPC_WIFI_UP and EEEPC_WIFI_DOWN
because I didn't know what to do with it otherwise
In acpi-eeepc-generic.conf I changed WIFI_DRIVER to ath_pci, because I use the
madwifi-newhal-svn-driver with the stock kernel. I use wicd for network-connections.
Is this the right way?
Every key works as expected (did not test xrand though, is says "clone" for each press).
Yanaar

Cool my first 900A user!!

You did exactly what you had to do Some variables are there if you need them. But if you don't then there is no harm in commenting/deleting them. I might want to shut down wicd when not using wifi but this is totally up to you. I though there was no use to have wicd (daemon+tray) running if there was no connection available. But them maybe you still want the wired connection... So its all up to you

Now as for why the KEY_Fn_F2 variable is an array. When I got first a 901, I checked the acpi events generated by the keypress. There was some key combination that always reported the same event. For example "volume down" was always volume down. But there was other keys which generated events based on the actual state of the hardware. For example the FnF2 combination reported "00000010" when the network was up and "00000011" when it was down. So the same key generated two events depending on the hardware state... I think it happened also on my 1000 when I received it. But now I can't reproduce that. So it might be a kernel/bios/something issue...

Anyway, set it so it works. Could you tell me also which kernel your using and which version? Maybe in the future the default file for the 900A can reflect your changes.

If you look at the 1000 config file, you'll see that:

EEEPC_WIFI_TOGGLE=${KEY_Fn_F2[0]}
EEEPC_WIFI_UP=NONE
EEEPC_WIFI_DOWN=NONE

which is basically what you did. I kept the KEY_Fn_F2 as an array, but only its first element is associated with the toggling.

Yanaar · 2009-02-01 16:33:49

big_gie wrote:

Cool my first 900A user!!

I'm proud

big_gie wrote:

You did exactly what you had to do Some variables are there if you need them. But if you don't then there is no harm in commenting/deleting them. I might want to shut down wicd when not using wifi but this is totally up to you. I though there was no use to have wicd (daemon+tray) running if there was no connection available. But them maybe you still want the wired connection... So its all up to you

Actually shutting wicd up and down works quite fine. In acpi-eeepc-generic.conf there were allready these lines:

COMMANDS_WIFI_POST_UP=("/etc/rc.d/wicd start" "/bin/su $XUSER --login -c \"wicd-client\"")
COMMANDS_WIFI_PRE_DOWN=("pkill wicd-client" "/etc/rc.d/wicd stop" "pkill wpa_supplicant" "pkill dhcpcd")

That's why I mentioned that I indeed use wicd, so nothing to change here for me.

big_gie wrote:

Now as for why the KEY_Fn_F2 variable is an array. When I got first a 901, I checked the acpi events generated by the keypress. There was some key combination that always reported the same event. For example "volume down" was always volume down. But there was other keys which generated events based on the actual state of the hardware. For example the FnF2 combination reported "00000010" when the network was up and "00000011" when it was down. So the same key generated two events depending on the hardware state... I think it happened also on my 1000 when I received it. But now I can't reproduce that. So it might be a kernel/bios/something issue...

Haha, what I first thought was that other models of Eee Pc might have two buttons for handling wifi. But then I thought that I never saw this on even bigger laptops and that it would be totally ridiculous on little Eees. And - what is more important - it does not make any sensse, because you cannot shut wifi a little more on or off like brightness or volume
That's why I was confused - I thought one button can generate only one event.
But when you say some of your buttons reported indeed different combinations I would stay with your suggestion to say NONE to those I do not need.
One day this might change again after a kernel-update or so and then I wouldn't know how to call this

big_gie wrote:

Anyway, set it so it works. Could you tell me also which kernel your using and which version? Maybe in the future the default file for the 900A can reflect your changes.

Would be great and I like to help.
My kernel is 2.6.28-ARCH, 2.6.28.2-1 to be more precisely, it's the regular kernel.
Keys are nearly the same, exept that only one code is reported:
KEY_Fn_F2="00000010" # Wifi toggle
KEY_Fn_F5="00000030" # XRandR

But setting EEEPC_XRANDR_TOGGLE=KEY_Fn_F5 and the other to NONE seems to have no effect. When I leave it to EEEPC_XRANDR_TOGGLE=NONE and use the array, it just reports "clone". Hmm.

Also, the 900A does not have Silverkeys - as long as you do not refer to the power button and the mouse buttons, which are silver.
I assume these silver buttons are additional buttons like multimedia keybords have?
I commented those, too.

So, if you have any further questions, just ask, I'm glad to help

Yanaar

big_gie · 2009-02-01 17:15:27

Yanaar wrote:

Haha, what I first thought was that other models of Eee Pc might have two buttons for handling wifi. But then I thought that I never saw this on even bigger laptops and that it would be totally ridiculous on little Eees. And - what is more important - it does not make any sensse, because you cannot shut wifi a little more on or off like brightness or volume
That's why I was confused - I thought one button can generate only one event.
But when you say some of your buttons reported indeed different combinations I would stay with your suggestion to say NONE to those I do not need.
One day this might change again after a kernel-update or so and then I wouldn't
know how to call this

Yeah I did not understand why two events were generated before, but now only one. It probably depended on the kernel...

Yanaar wrote:

Keys are nearly the same, exept that only one code is reported:
KEY_Fn_F2="00000010" # Wifi toggle
KEY_Fn_F5="00000030" # XRandR

The "KEY_Fn_Fx=..." variables should just be what the key combinations generates. You map these in the following "EEEPC_...=..." variables. I kept Fn+F2 and Fn+F5 as arrays of multiple values just to keep the value if the old effect of multiple events generation comes back. I'll set the 900A (probably all other 90X also) to the same as the 1000 then:

EEEPC_WIFI_TOGGLE=${KEY_Fn_F2[0]}
EEEPC_WIFI_UP=NONE
EEEPC_WIFI_DOWN=NONE

Yanaar wrote:

But setting EEEPC_XRANDR_TOGGLE=KEY_Fn_F5 and the other to NONE seems to have no effect. When I leave it to EEEPC_XRANDR_TOGGLE=NONE and use the array, it just reports "clone". Hmm.

Did you meant "EEEPC_XRANDR_TOGGLE=$KEY_Fn_F5" instead of "EEEPC_XRANDR_TOGGLE=KEY_Fn_F5"? If you forget the "$", it sure wont work
I'm am in the process of writting a helper script for xrandr screen toggling. I was not 100% satistified with what I had in the configuration file. I did not used the key yet: I was using "lxrandr" from the community/lxrandr package. Its even easier
If you want to take a look at the screen toggle screen, please look at the svn branch 0.7. ( http://code.google.com/p/acpi-eeepc-gen … e%3Dclosed )

Yanaar wrote:

Also, the 900A does not have Silverkeys - as long as you do not refer to the power button and the mouse buttons, which are silver.
I assume these silver buttons are additional buttons like multimedia keybords have?

I did not know the 900A did not have the "silver keys". These are located above the F2 to F6 keys. See this picture: http://www.digitalburn.com/wp-content/g … _hires.jpg If you don't have these keys, then its no harm to associate something to them! I'll remove the events from the 900A configuration file.

Thanx for your feedback

big_gie · 2009-02-03 16:44:05

I've uploaded a new version of my acpi script package (0.7.0).
http://aur.archlinux.org/packages.php?ID=23318
http://code.google.com/p/acpi-eeepc-generic/

der_joachim · 2009-02-04 18:35:53

Bad news. The new non-svn version won't install. Everything goes well until the MD5 checksum. The file acpi-eeepc-generic.conf fails the MD5 check. The rest appears to work. I've tried it several times from both work and home. I made sure that the downloaded package was not in my pacman cache, so I was forced to redownload.

Earlier versions worked mostly on my EEE900, but I haven't had the time yet to troubleshoot any issues.

big_gie · 2009-02-04 18:38:59

Yeah I know about the md5 issue. Sorry about that.
But that does not affect in any way the package or its functionality Just update the md5sum, or delete the md5sums array from the pkgbuild.

der_joachim · 2009-02-05 18:55:33

Disabling the MD5sums did the trick. Thank you.

twhayes · 2009-02-22 21:04:26

big_gie - Everything is working great on my eeePC 904 with one exception, the wifi toggle. It toggles off with no problem, but then will never toggle back on. I'm not familiar enough with 'rfkill', but I think it must be doing something because once I toggle the wifi off, there is no way to get it back. 'ifconfig' doesn't show the adapter and the only way I can get it turned back on is to reboot.

Any ideas or suggestions?

BTW, when I ran the dmidecode command, it returned '1000H' as the model for my 904.

Thanks for a super piece of work. Really made it much easier to get everything set up on my new netbook. Really appreciate all of your time.

tim

big_gie · 2009-02-22 21:36:57

twhayes wrote:

big_gie - Everything is working great on my eeePC 904 with one exception, the wifi toggle. It toggles off with no problem, but then will never toggle back on. I'm not familiar enough with 'rfkill', but I think it must be doing something because once I toggle the wifi off, there is no way to get it back. 'ifconfig' doesn't show the adapter and the only way I can get it turned back on is to reboot.
Any ideas or suggestions?

Take a look there:
http://code.google.com/p/acpi-eeepc-gen … tail?id=11
Basically, just add this:
options pciehp pciehp_force=1
to your /etc/modprobe.conf file. This might not be needed with kernel 2.6.29 when it will come out, but until now you need this
If it does not work open a new issue.

twhayes wrote:

BTW, when I ran the dmidecode command, it returned '1000H' as the model for my 904.

Hum... thats weird. I can't really do anything. It's probably in the BIOS. But then it probably saved your ass because there is no config file for the 904, only 904HD Does all the keys work? It would mean the 904 is the same as the 1000H...

I'll post v0.8.1-1 in a minute. It contains some small fixes and cleanups.

twhayes · 2009-02-23 18:33:38

big_gie wrote:
Take a look there:
http://code.google.com/p/acpi-eeepc-gen … tail?id=11
Basically, just add this:
options pciehp pciehp_force=1
to your /etc/modprobe.conf file. This might not be needed with kernel 2.6.29 when it will come out, but until now you need this smile
If it does not work open a new issue.

Worked like a champ. Thanks.

big_gie wrote:
Hum... thats weird. I can't really do anything. It's probably in the BIOS. But then it probably saved your ass because there is no config file for the 904, only 904HD wink Does all the keys work? It would mean the 904 is the same as the 1000H...

I've seen in the eeePC forum that the 904HA is the same as the 1000D except for screen size so that makes sense. I just updated my BIOS and the asus web site also id'd the computer as 1000D. And, yes, all of the keys are working so I it appears safe to assume the two are the same.

Thanks for your help.

big_gie · 2009-02-23 18:35:23

No prob. Glad it helped and that it is usefull!

big_gie · 2009-04-01 01:35:24

New version: 0.9.0-1
Many new things, see changelog on homepage.

Platypus · 2009-08-19 09:34:26

I seem unable to get wifi toggle to execute multiple commands in COMMANDS_WIFI_POST_UP in /etc/conf.d/acpi-eeepc-generic.conf (and I assume other places as well but that's what I've been playing with.

I'm very much a novice using any kind of Linux but I've been able to discover that the execute_commands function in the ...generic-functions.sh script seems to be treating:

COMMANDS_WIFI_POST_UP=("/etc/rc.d/wicd start" "@wicd-client")

as one string, and is not splitting up the commands.

I'm using a 901 with the stock kernel and fluxbox.

Just as I thought I was getting the hang of abandoning windows I've hit this wall. I can't tell how this should work.

fito · 2010-01-09 12:29:41

big_gie wrote:

Any ideas or suggestions?
Take a look there:
http://code.google.com/p/acpi-eeepc-gen … tail?id=11
Basically, just add this:
options pciehp pciehp_force=1
to your /etc/modprobe.conf file. This might not be needed with kernel 2.6.29 when it will come out, but until now you need this
If it does not work open a new issue.

I'm still having this problem. Any idea?

Thanks.-

Elline · 2011-05-23 18:13:05

wimac wrote:

I can't get the volume keys fn-F7 fn-F8 and fn-F9 working on my 900 any ideas?

Is this thread closed? I'm having this issue too. Will dig in it later.

Last edited by Elline (2011-05-23 18:13:37)

big_gie · 2011-05-23 20:20:45

Hi Elline, it's easier for me to track if you open an issue on the github page:
https://github.com/nbigaouette/acpi-eee … ric/issues

Elline · 2011-05-24 22:44:59

Thank you for the reply. But I feel shy to open new issue because I'm a newbie and at this time I'm not even sure these scripts working at all. I just did the usual installation from AUR and checked configuration file /etc/conf.d/acpi-eeepc-generic.conf. In fact it seems not to work at all because even brightness buttons does't provide OSD notifications and seems to be controlled by BIOS itself.
I can open an issue but afraid that it is my fault. Maybe something I should check? Some way to find these scripts working at all.

Well, I just found that it needs to add acpid to DAEMONS array, but I missed that. It now works, partially, but sure it again my fault. Sorry for trouble.

Last edited by Elline (2011-05-24 22:52:55)

Arch Linux

#1 2009-01-21 17:56:55

New ACPI events handling script for all Asus EeePC

#2 2009-01-26 16:37:34

Re: New ACPI events handling script for all Asus EeePC

#3 2009-01-26 17:05:54

Re: New ACPI events handling script for all Asus EeePC

#4 2009-01-27 22:09:28

Re: New ACPI events handling script for all Asus EeePC

#5 2009-01-28 03:22:58

Re: New ACPI events handling script for all Asus EeePC

#6 2009-01-29 02:36:35

Re: New ACPI events handling script for all Asus EeePC

#7 2009-01-29 02:45:46

Re: New ACPI events handling script for all Asus EeePC

#8 2009-01-29 21:54:30

Re: New ACPI events handling script for all Asus EeePC

#9 2009-01-29 22:05:04

Re: New ACPI events handling script for all Asus EeePC

#10 2009-02-01 16:33:49

Re: New ACPI events handling script for all Asus EeePC

#11 2009-02-01 17:15:27

Re: New ACPI events handling script for all Asus EeePC

#12 2009-02-03 16:44:05

Re: New ACPI events handling script for all Asus EeePC

#13 2009-02-04 18:35:53

Re: New ACPI events handling script for all Asus EeePC

#14 2009-02-04 18:38:59

Re: New ACPI events handling script for all Asus EeePC

#15 2009-02-05 18:55:33

Re: New ACPI events handling script for all Asus EeePC

#16 2009-02-22 21:04:26

Re: New ACPI events handling script for all Asus EeePC

#17 2009-02-22 21:36:57

Re: New ACPI events handling script for all Asus EeePC

#18 2009-02-23 18:33:38

Re: New ACPI events handling script for all Asus EeePC

#19 2009-02-23 18:35:23

Re: New ACPI events handling script for all Asus EeePC

#20 2009-04-01 01:35:24

Re: New ACPI events handling script for all Asus EeePC

#21 2009-08-19 09:34:26

Re: New ACPI events handling script for all Asus EeePC

#22 2010-01-09 12:29:41

Re: New ACPI events handling script for all Asus EeePC

#23 2011-05-23 18:13:05

Re: New ACPI events handling script for all Asus EeePC

#24 2011-05-23 20:20:45

Re: New ACPI events handling script for all Asus EeePC

#25 2011-05-24 22:44:59

Re: New ACPI events handling script for all Asus EeePC

Board footer