acpi-eeepc-generic 1.0rc2-0.1
http://code.google.com/p/acpi-eeepc-generic/
ACPI scripts for EeePC netbook computers (700, 701, 900, 900A, 901, 904HD, S101, 1000, 1000H, 1000HD, 1000HE)
unsupported :: system
Maintainer: big_gie
Votes: 141
License: GPL3
Last Updated: Sun, 03 Jan 2010 19:37:35 +0000
First Submitted: Tue, 20 Jan 2009 19:42:59 +0000
Dependencies acpid dmidecode xorg-server-utils
I Just Bought a asus 1005PE, and i've got a little problem with brigthness.
In fact, it seems that the minimum and maximum levels are wrong so that when you go trought the minimum to the maximum, you loop into brightness level.
for exemple, you start from zero, you go to 15, which is the maximum level in /sys/devices..., and brightness will go up, then come back to minimum, then up again, for three level, the go up again.
Any questions or ideas?
Best Regards.
If it reports as a 1000H, then nothing should be changed: everything should already be there. Just open an issue here http://code.google.com/p/acpi-eeepc-generic/issues if you spot something which does not work.
it returns as 1000H
things seem to be working so far, i tested all the hotkeys and they seem too work, il continue to test it.
let me know if you want anything specific tested.
I don't have information on the 1000HA for now, but you are welcomed to submit them!
Basically what you can do it copy a configuration from a similar model, test all keys and report back. For example:
# EEEPC_MODEL="$(sudo dmidecode -s system-product-name | sed 's/[ \t]*$//')"
# sudo cp /etc/acpi/eeepc/models/acpi-eeepc-1000-events.conf /etc/acpi/eeepc/models/acpi-eeepc-${EEEPC_MODEL}-events.conf
Also, could you give me the exact value of EEEPC_MODEL?
echo ${EEEPC_MODEL}
Once the config file exist, then yes, it should work!
does this work with the 1000HA, or just the 1000/H?
Here's RC2. There is only 3 issues on the tracker that I would like to fix before a 1.0 release:
http://code.google.com/p/acpi-eeepc-generic/issues/list?q=milestone=Release1.0
Help is welcome!
For the pleasure of all, here is 1.0-rc1. Please test it and report any issues here: http://code.google.com/p/acpi-eeepc-generic/issues
@harveythedog
This has been fixed in svn. I'm waiting to fix the last issues before releasing the 1.0. Maybe I'll do a -rc soon, specifically if I don't hear from people who opened the issues.
My 900 required this to fix the mute/unmute. Previously it would just mute everything and stay that way. Great package otherwise!
By Kludge 26th Oct: "this is easily resolved by replacing 'ALSA_MUTE_MIXER' with 'output_mixers' in line 198 of acpi-eeepc-generic-functions.sh."
HTD.
Open an issue @ http://code.google.com/p/acpi-eeepc-generic/issues/ so I can track it. Here is not the best place for that.
@big_gie
Hmm, then it means my mute-status-toggling is not working. I've taken a quick peak at all the config files, and it all seem fine. Any ideas?
@unlimited
I don't understand what you mean bu toggling the "sound" instead of "muting it"? Look at the file /etc/conf.d/acpi-eeepc-generic.conf The option COMMANDS_MUTE will let you control what command to run when the mute keyboard shortcut is pressed. By default it call alsa_toggle_mute, a function defined in the file /etc/acpi/eeepc/acpi-eeepc-generic-functions.sh which just toggles the mute status of all output mixers. But you can change the COMMANDS_MUTE option to anything you want.
As for the delay, I have this too. I guess it is caused by acpid and bash. But nobody did any benchmarking/timing so it is hard to tell.
acpi-eeepc-generic is written in bash, so it is easy to understand and hack on. Feel free to look up the scripts in /etc/acpi/eeepc . The main one is /etc/acpi/acpi-eeepc-generic-handler.sh which decides which command to run based on which key was pressed. /etc/acpi/eeepc/acpi-eeepc-generic-functions.sh contains most of the useful/generic functions. All other scripts in /etc/acpi/eeepc/ are doing specific tasks. Good luck! ;)
Hi! I'd like to thank big_gie for this wonderful package! I am a new linux user using Asus eeepc 1000HG, which is pretty similar to 1000H (the only config file I've looked at as of yet). There are 2 major things I'd like to get fixed. One is the volume mute option. Is it possible to toggle the sound instead of just muting it? The second is that adjusting the volume up/down seems to have a delay in the actual sound volume. It gets pretty annoying after pressing up/down a few times just to get the right volume. If anyone knows how to solve the problems, would you please also tell me *how* you did it? I'd like to pick up a few linux coding howtos on the way! Thanks!
@Celos
You don't need to touch the acpi-eeepc-*-events.conf files. Normally you only edit the /etc/conf.d/acpi-eeepc-generic.conf file. If, and only if, your eeepc is not yet supported, you'll have to create a new acpi-eeepc-????-events.conf file, based on one written for a similar model. The question mark would match your model.
What model do you have? The supported ones are:
1000, 1000H, 1000HD, 1000HE, 1005-HA-H, 1005HA, 1008HA, 700, 701, 900, 900A, 901, 904HD, S101
But any others could be added.
Hi,
I don't understand something about the configuration of this packages. The conf files "acpi-eeepc-100***-events.conf" what are they used for ?
If i want to configure my acpi, i need to edit /etc/conf.d/acpi-eeepc-generic.conf, but what about acpi-eeepc-100***-events.conf, what do i need to do with this file ?
Thanks
@toofishes
Yes a lot a cruft accumulated since the start of the project. I've done a lot of cleanup today, can you check svn repo and comment back?
To all others, if you still have problems, make sure you either open an issue on the project page or response to questions I might ask.
Oh you did not just restart a daemon in a post-install...have you been around here long?
And what is with the novel in the install message? Move it to a wiki article or something, that is beyond ridiculous (I almost missed the daemon restart in all of that).
Thanx. I remember debating with myself over this. Should "xrandr" be called everytime or just once? I though I had put a way to get new values, but I might have forgotten to put it.
re #2 below (resolution toggling):
in /etc/acpi/eeepc/acpi-eeepc-generic-toggle-resolution.sh:
tmp_xrandr="$EEEPC_VAR/lvds-modes"
if [ -e "$tmp_xrandr" ]; then
LVDS_XRANDR=$(cat $tmp_xrandr)
else
LVDS_XRANDR=$(xrandr > $tmp_xrandr)
fi
creates the file 'lvds-modes' with the resolution at the time of the file's creation marked with "*". the script then preceeds to switch to the next resolution in the list. *HOWEVER*, the file is never deleted, so '-e $tmp_xrandr' is always true after the first run. as a result, the "current" resolution is never updated and each press of the associated key "switches" the resolution to the second in the list after the resolution at the time of the first invocation.
this can be solved by either, (a):
removing the the if-then-else-fi and leaving only 'LVDS_XRANDR=$(xrandr > $tmp_xrandr), executed at each invocation
, or (b), changing:
LVDS_CURRENT=$(cat $tmp_xrandr | ...
to:
LVDS_CURRENT=$(xrandr | ...
if google ever lets me reset my password, i'll start filing actual bug reports ;)
Hi kludge, I'll take a look at these in the next few days.
re #1 below:
the '-s' option to synclient appears to be deprecated. 'sed -i s/synclient -s/synclient/g /etc/acpi/eeepc/acpi-eeepc-generic-toggle-touchpad.sh' seems to do the trick.
p.s.: i really should just send you patches, but i do it so rarely i always have to look up how, and tonight i've had too much wine to relearn diff.
yo big_gie,
1) there's a bug in acpi-generic-toggle-touchpad.sh. it's not actually toggling the touchpad; each press of the key "Fn_F3" produces "touchpad enabled." something is not setting/detecting the touchpad state correctly. haven't tracked it down yet, but i just might in another comment...
2) there's something wrong with acpi-eeepc-generic-toggle-resolution over here. it will toggle down to a lower resolution, but won't scale back up. again, i might track this one down for you, but for now here's heads up.
3) The duplication of the second silver button and fn_f4 on EEEPC_RESOLUTION is kinda broken, imho. where your acpi-eeepc-1000HE-events.conf has:
EEEPC_BLANK=$KEY_SILVER1
EEEPC_RESOLUTION=$KEY_SILVER1 # Duplicate of Fn+F4
EEEPC_USER1=$KEY_SILVER2
EEEPC_USER2=$KEY_SILVER3
i would suggest:
EEEPC_BLANK=$KEY_SILVER1
EEEPC_BUTTON_RESOLUTION=$KEY_SILVER2
EEEPC_USER1=$KEY_SILVER3
EEEPC_USER2=$KEY_SILVER4
now all four silver keys are in play.
then, in acpi-generic-handler.sh, replace:
$EEEPC_RESOLUTION) # Silver function button 2 (Resolution)
with:
$EEEPC_BUTTON_RESOLUTION) # Silver function button 2 (Resolution)
Thanx kludge ;)
For 1) I've fixed that this morning (its in revision r505)
As for 2), the script will try to mute all playback mixers available. It's the tradeoff for the autodetection and simplification for the user... But if you have an idea to skip the mute toggle for mixers which do not support it, let me know!
And finally for 3), the output is only shown (or should only be shown) when running from a terminal. I though of piping everything to /dev/null, but then you loose the verbose output. Since everybody should run the scripts from the special keys, the output should always be hidden. And its easier for debugging.
1) found a bug in the 'volume_is_mute' function of acpi-eeepc-generic-functions.sh that breaks the 'alsa_toggle_mute' function:
function 'volume_is_mute' relies on the ALSA_MUTE_MIXER variable, which is no longer set in acpi-eeepc-generic.conf. the function will always return a value of zero, breaking the 'alsa_toggle_mute.'
this is easily resolved by replacing 'ALSA_MUTE_MIXER' with 'output_mixers' in line 198 of acpi-eeepc-generic-functions.sh.
2) at least on my 1000he, the PCM device cannot mute or unmute, so the alsa_toggle_mute's invocation of 'amixer set PCM [un]mute' throws a harmless "amixer: Invalid command!" error.
3) amixer has the "-q" option to suppress output. adding that to any invocation of amixer the doesn't need to produce output might make the scripts a little cleaner.
Thanks so much big_gie, I was going to come online tonight and beg for a release for my 1005HA.
I'm posted an issue on the google code page.
Please keep up the good work.
I haven't by any means tested everything yet, but I forgot ot mention on my ticket that sound controls don't work by default.
And for anyone else looking here for 1005HA, I used ath9k as the wireless module and it appears to work.
I just posted a 1.0 release candidate. Please test and report back!
For the wireless that went wrong, it was because the BIOS now toggle the rfkill which confuses the script. If its the case for yours, just comment/disable/empty the wireless script toggle in the config file.
The Super Hybrid Engine script is ready. Please test!
I also fixed the alsa mute and volume: for the mute, everything is done automatic! for the volume you just need to set the mixer you want to control in the config file.
I also added many other stuff, including other models.
Please test the 1.0 branch! Now in beta ;) Report everything on the google issue page.
Re the wireless toggle script, this is also being discussed here: http://bugzilla.kernel.org/show_bug.cgi?id=14400
I added support for the 1005HA in the 1.0 branch. I took the config from the 1008HA since the keyboard seem the same. But the events generated might be different. Could you try to install the 1.0b from svn and test the events? You can always enable the:
# Show the ACPI key event
KEY_SHOW="1"
option in /etc/conf.d/acpi-eeepc-generic.conf and report back the events associated with each keys...
Note that for me, the wireless toggle script is broken. It seems a bug in the kernel is the cause (since 2.6.31)
I second the request by ungraven, what to do for 1005HA?
big_gie, the output of dmidecode | grep -i "Product Name" for the 1005HA is: Product Name: 1005HA
Yes in my configuration notifications in the center of the screen.
Yes indeed amixer stuff has been fixed. I'll add the dzen stuff ;) Notification is in the center of the screen? Like in the middle?
I looked to 1.0 branch - amix iteraction fixed. But, could you please add dzen params pass?
After last update up 2.6.31 and new ALSA, iteractions with amixer should be changed, like this patch:
-------- cut begin
--- acpi-eeepc-generic-functions.sh.orig 2009-09-09 21:35:43.781320609 +1100
+++ acpi-eeepc-generic-functions.sh 2009-10-15 02:10:06.955607872 +1100
@@ -93,7 +93,7 @@
duration=$3
[ "x$duration" == "x" ] && duration=${NOTIFY_DURATION}
duration=$(( $duration / 1000 )) # Dzen2 duration is in second
- cmd="(echo \"$1\"; sleep $duration) | /usr/bin/dzen2 &"
+ cmd="(echo \"$1\"; sleep $duration) | /usr/bin/dzen2 $DZEN_PARAM &"
send_generic "${cmd}"
}
@@ -165,7 +165,7 @@
### Verify if volume if muted ###################################
function volume_is_mute() {
# 1 is true, 0 is false
- on_off=`amixer get ${ALSA_MUTE_MIXER} | grep -A 1 -e Mono | grep Playback | awk '{print ""$4""}'`
+ on_off=`amixer get ${ALSA_MUTE_MIXER} | grep -A 1 -e Mono: | grep Playback | awk '{print ""$6""}'`
is_muted=0
[ "$on_off" == "[off]" ] && is_muted=1
echo $is_muted
@@ -173,7 +173,7 @@
### Return the volume level #####################################
function get_volume() {
- echo `amixer get ${ALSA_MAIN_MIXER} | grep -A 1 -e Mono | grep Playback | awk '{print ""$5""}' | sed -e "s|\[||g" -e "s|]||g" -e "s|\%||g"`
+ echo `amixer get ${ALSA_MAIN_MIXER} | grep -A 1 -e Mono: | grep Playback | awk '{print ""$4""}' | sed -e "s|\[||g" -e "s|]||g" -e "s|\%||g"`
}
### Return the mixer ############################################
-------- cut end
This patch also add ability to pass params to dzen2, so new variables in /etc/conf.d/acpi-eeepc-generic.conf is needed:
DZEN_W=300
DZEN_H=100
DZEN_PARAM="-x $((1024/2-$DZEN_W/2)) -y $((600/2-$DZEN_H/2)) -w $DZEN_W -h $DZEN_H"
With this params and my patch dzen dialog shown as box 300x100 pixels at screen senter.
dzen2 more quickly than kdialog & libnotify use it for speed up! :-D
Can you post the output of:
sudo dmidecode | grep -i "Product Name"
Is it "1005-HA-H" exactly?
please add alsa-utils to the dependencylist, took me while to figure out why the volume/mute buttons didn't work as expected. I was missing amixer...
btw, I am running this utility on a Eee 1005-HA-H and it works great - copied the 1000HE definition file.
Forgot to say, this work is in the 1.0 branch, located here:
http://code.google.com/p/acpi-eeepc-generic/source/browse/#svn/branches/1.0
To try it:
svn checkout http://acpi-eeepc-generic.googlecode.com/svn/branches/1.0 acpi-eeepc-generic-1.0b
I started fixing issues on the google code page. Once all of the important/fizable issues are fixed, I'll release 1.0.
Meanwhile, I highly encourage you all to test it and report any regressions, new bugs and eatures you would like in 1.0.
As I already stated, asusosd is out of the question. It is not only the osd part but also listen by itself to acpi. It is a mess of code, only available in a 2GB file on a freaking slow ftp...
Feel free to hack on it and submit any code.
As for the stack notification, I fully agree, but this is a kde issue (I suspect you are using kde, like I do). There is no options (or no options that I know of, feel free to enlighten me) to kdialog to prevent this stacking. Maybe you could suggest that to the kde team?
If you don't like KDE's notification, you could always use libnofity which does not stack notifications. You could even replace it with notify-osd from ubuntu (http://aur.archlinux.org/packages.php?ID=25256). But this one is slow: instead of stacking notifications, they delay them. So you end up with volume notifications from a minute ago...
I took a look at clutter a couple of months ago to see if it could be used for osd. It can be, but nobody wrote something yet so I would have to do it, which I don't have time now.
I will fix all reported issues this fall.
Meanwhile, feel free to submit any patch to the issue page!
I second Malo's suggestion. Stacked notifications are bad... especially for the sound.
New issue posted: http://code.google.com/p/acpi-eeepc-generic/issues/detail?id=36
Thank you so much for this great work. Only one suggestion.. Is it possible to add Asusosd as notification system? When you change the brightness or change sound levels, you get many stacked notification windows.. A progressive bar like Asusosd is much better..
@dlin: tracked @ http://code.google.com/p/acpi-eeepc-generic/issues/detail?id=31
Thanks this useful package, but, there are something must modify on my eeepc S101.
1. All synclient command in acpi-eeepc-generic-toggle-touchpad.sh should use shm form. (add -s option)
2. There is a hotkey above F1 and F2. /etc/acpi/eeepc/models/acpi-eeepc-S101-events.conf KEY_SILVER2="00000039".
I set this key to toggle my touchpad.
Ok that will come in the next release ;)
Thanx for pointing it out.
Could you remove the conflict on eee-control. There's no need for it to be set.
There are no file conflicts. eee-control's main features are fan control and fsb underclocking which acpi-eeepc-generic does not provide. Both packages offer keyboard shortcuts, but this can be disabled in both, nor does having both enabled actually cause any problems.
The same could probably be said for eee-fan, though I havn't tried it.
For suspending an Eee 1000H, I had better luck installing uswsusp and setting
SUSPEND2RAM_COMMANDS=("s2ram -f")
in /etc/conf.d/acpi-eeepc-generic.conf. Any more "manual" methods that I tried led to a black display on resume. (hibernate-script works too, even more high-level than s2ram.) Btw the Eee-specific wiki pages should really advertise better the generic suspend wiki pages - I had quite a bit of trouble until I realized I had to rebuild the ramdisk first of all :)
big_gie, like LemmingKing I had the below issue. I tend to work from the terminal (out of X) quite a bit so having this working properly was important. The cure for me was to ensure that i915 was loaded prior to sleep. Thanks for all the good work.
> Comment by: LemmingKing on Fri, 03 Apr 2009 23:20:47 +0000
> 3) Very small issue. Really small. My device can't wake up properly when suspended in console mode (without X): display refuses > to turn on. When X was started and killed, all is fine, but when X haven't been started at all - something goes wrong. This is > _really_rare_ case, so this might be left as is without any harm. I will try to find a solution later, but I'm afraid, that my > solution will work only on my device, so... it would be great if you tried to suspend/resume your eee before starting X.
big_gie, like LemmingKing I had the below issue. I tend to work from the terminal (out of X) quite a bit so having this working properly was important. The cure for me was to ensure that i915 was loaded prior to sleep. Thanks for all the good work.
> Comment by: LemmingKing on Fri, 03 Apr 2009 23:20:47 +0000
> 3) Very small issue. Really small. My device can't wake up properly when suspended in console mode (without X): display refuses > to turn on. When X was started and killed, all is fine, but when X haven't been started at all - something goes wrong. This is > _really_rare_ case, so this might be left as is without any harm. I will try to find a solution later, but I'm afraid, that my > solution will work only on my device, so... it would be great if you tried to suspend/resume your eee before starting X.
Right now it does not. But the 1000HA is probably the same as the 1000 or 1000HE or... So try to copy the file /etc/acpi/eeepc/models/acpi-eeepc-1000-events.conf to /etc/acpi/eeepc/models/acpi-eeepc-1000HA-events.conf If both models (1000 and 1000HA) have the same hardware, it should work without anything else...
If not, just open an issue on the google page. I will add support for it.
Does this version support the Eee PC 1000HA?
Regards,
in the 1000HE model config:
EEEPC_RESOLUTION is assigned twice thus making the 2nd silver key not function.
New version 0.9.2-1 out!
Changelog
* Switching to VT1 should not be needed for suspending to ram (option in config file to get back switching)
* Configuration of different XRandR modes (Any combinations of clone, VGA only or both)
* Catch (useless) events generated by suspending to prevent notifications
* X access control disabling has been removed (should not be necessary)
* OSD duration now configurable
* Many fix and cleanups in the handler script
* Fix dzen notifications (delays)
* Fix notifications by quoting text
* Added modules for madwifi and intel (4965 and such)
* Modules loading and unloading functions
* Use SAVED_STATES in device_restore()
* Use "eval" to evaluate calls in variables
* Fix wifi/wlan name problems
* Harmonization of events files
* Many other small fixes and cleanups
It's already fixed in svn at revision 416 ;)
See:
http://code.google.com/p/acpi-eeepc-generic/source/detail?r=416&path=/trunk/acpi-eeepc-generic-functions.sh
I hope to release an updated version soon.
There seems to be a bug in the restore-functionality for WiFi. The script /etc/acpi/eeepc/acpi-eeepc-generic-functions.sh defines a function "device_restore" that checks the variable ${RADIO_SAVED_RADIO} in order to decide what to do (i.e. enable or disable the device), but that variable is never set anywhere. I guess that it has been renamed in a recent versions, but the name wasn't updated in that particular script.
big_gie,
time's fast and .29 is in 'core' since today, so .28 is legacy already :)
If you want to support this legacy, you may write something like this to config:
## If you have madwifi drivers and you are still using kernel 2.6.28, you should:
## - remove all the WIFI_DRIVERS variants
## - and setup your wifi commands like this:
#COMMANDS_WIFI_POST_DOWN=("sleep 1 && /sbin/modprobe -r wlan_tkip wlan_ccmp ath_pci ath_rate_sample ath_hal wlan_scan_sta wlan pciehp")
#COMMANDS_WIFI_PRE_UP=("/sbin/modprobe -a wlan_tkip wlan_ccmp wlan_scan_sta ath_pci ath_rate_sample ath_hal wlan")
#COMMANDS_WIFI_POST_UP=("/sbin/modprobe pciehp pciehp_force=1")
(Tried this with latest svn version and kernel 2.6.28. It works)
Thank you again :)
Hi LemmingKing,
Thanks a lot for your review. It seemed I was overconfident about my capabilities to fix this while doing something else! ;)
I reverted back all modifications so there is no more quirks at all. The wifi drivers are now ("wlan_tkip" "wlan_ccmp" "ath_pci" "ath_rate_sample" "ath_hal" "wlan_scan_sta" "wlan") for madwifi (the order they will be loaded and unloaded).
Does it still needs any pre/post_up/down "manual" quirks? I can't find any in my notes so if you still need it just let me know which.
I also included your suggestion for the mixer.
Thanx again for all your review. And I'm glad you defeated madwifi ;)
Hi, big_gie, good news!
Found out what's with kernel 2.6.29 (got latest yesterdays release from testing).
1. In .28 modules must be unloaded ater turning wifi off, and here in .29 - BEFORE that. And if modules are left in memory - errors occur! So wlan_scan_sta and wlan, which were sometimes left, produced these errors!
Also, to kill them all properly every time as wifi_drivers their order should be changed to:
("wlan_tkip" "wlan_ccmp" "ath_pci" "ath_rate_sample" "ath_hal" "wlan_scan_sta" "wlan")
2. NO MORE QUIRKS! Really, (un)loading pciehp is not needed with 2.6.29! That's enough to just load it at boot time. Don't know if it is newest version enhancement or it was my mistake (mistesting) last time... Anyway, sorry for that :)
So, now I have latest madwifi revision 3986, latest kernel from 'testing', and your scripts at revision _426_ (not 429 nor 430) working fine together on my testing system. The only thing I've done with it to get it working is reordering modules. Of course quirks are turned off. Never had my wifi turning on/off so quikly before!
A bit later .28 kernel will be replaced with .29 in 'core', so quirks will not be needed any more (and even more, they will do things worse). So now, IMHO, all the madwifi quirks should be removed (except multiple module (un)loading, of course). But with commented POST_(UP|DOWN) config hack left for rare users with madwifi and kernel .28...
Also, -r426 is the most stable revision, I think, so that will be enough for now to just reorder madwifi example modules and clear out quirks from it to announce a new version in aur :)
ufff... madwifi is mad :) but finally defeated!
Thank you for your patience.
--- and a small enhancement in config file ---
I think, config would be simpler if sound configurations looked like this:
#################################################################
### Volume options
ALSA_MAIN_MIXER="PCM"
ALSA_MUTE_MIXER="iSpeaker"
COMMANDS_MUTE=("amixer set LineOut toggle" "amixer set ${ALSA_MUTE_MIXER} toggle")
COMMANDS_VOLUME_DOWN=("amixer set ${ALSA_MAIN_MIXER} 5%-")
COMMANDS_VOLUME_UP=("amixer set ${ALSA_MAIN_MIXER} 5%+")
Bye!
big_gie, I can't understand how should autodetection of madwifi work :)
1. In acpi-eeepc-generic-toggle-wifi.sh you set DRIVERS to madwifi_modules whether you found ath_* wlan_* modules or not (line 46)... so, it seems to me, that these modules will always be set as wifi drivers.
2. At the moment wifi is off and we need to turn it on, modules should not be present in memory, so autodetection with lsmod (line 40) will say that it's not madwifi.
Maybe, autodetection is not a good choise here?
Anyway, I couldn't get this version of acpi-eeepc-generic (I mean 429, but the latest 430 too) working at all :) even sound control died...
About my crashes... still can't find out what is happening, but already am not sure that these scripts aren't the reason of all of this...
I installed arch from the beginning to SD-card and tried it a bit. Version with (un)loading multiple modules produced errors on my clear new system!
But latest version from aur (not from Google svn) with initial configuration hacks worked fine! (have latest madwifi-newhal-svn revision 3986 and kernel 2.6.28 (will try 29 again soon)).
The only difference I see is the order of (un)loading modules and sending something to /sys/class/rfkill/rfkill0/state: in your scripts you unload modules before using rfkill, but my hack uses post_(up|down) commands, so modules are (un)loaded after rfkill'ing.
MadWifi drives me mad, really :)
Erm... I'm starting thinking, that it would be reasonable to revert scripts to their state before starting that all. At least they will work correctly with other drivers and there will be a way to make them work with madwifi... And they will have much prettier structure than now with those quirks :(
Wow that sucks... Sometimes drivers are a pain. I replaced the wireless card I had in my 1000 for a intel's 4965. The rt2860sta driver SUCKS. I mean, no work is put into it, power saving is bad, driver quality is horrible, etc.
I have checked the toggle case and you are right, I forgot to add it there too. It's in svn -r425. As for the sleep, its now disabled in -r426.
And finally, you can take a look at a try to autodetect madwifi drivers in -r429. You should not need a WIFI_DRIVERS in config file anymore (IF madwifi is detected, else you need it).
good luck with the debugging... ;)
big_gie,
I tried the version from svn... Strange things are happening :(
I started encountering annoying errors (kernel 'oops's) while loading modules. After that I can't continue working... But I dont'think, that this came from your scripts because even reinstalling old version didn't help.
I tried to update madwifi-newhal-svn package - no result. Updating kernel to 2.6.29 from 'testing' made things even worse: errors started to occur every echoing '0' to rfkill0/state (even without (un)loading modules). Downgrading kernel and madwifi back didn't help too.
So, I'm sorry, but my tests will be useless for a while, until I find out, what's happening. Will try to reinstall whole system...
About new version, I noticed something before my eee started behaving wrong.
First of all - you didn't add any madwifi quirks to 'toggle' case of acpi-eeepc-generic-toggle-wifi.sh. So, I'd enter following after device_toggle:
>> if [ "$WIFI_MADWIFI" == "yes" ]; then
>> # IS_ENABLED contains old value now
>> if [ "${IS_ENABLED}" == "no" ]; then
>> quirks_madwifi_post_up
>> else
>> quirks_madwifi_post_down
>> fi
>> fi
After that, modules 'wlan' and 'wlan_scan_sta' are sometimes left in memory (modprobe claims that 'wlan_scan_sta' is in use and 'wlan' is used by 'wlan_scan_sta', but after rfkill'ing '0' they could be unloaded safely). It could be solved by unloading them in post_down quirks.
Also, I wonder if it is necessary to 'sleep 1' after (un)loading each module. It takes too much time to turn wifi on/off when there are so many modules.
That's all for now. Thanks for your work :)
Bye
Thank you, big_gie!
I'll test it a couple of hours later.
About 'wlan' module: files wlan.ko, ath_pci.ko, ath_hal.ko and other 'wlan_*' and 'ath_*' modules are in madwifi package (madwifi-newhal-svn in my case), so I think, these modules are madwifi-special...
I can say, that Intel wifi (ipw2200) and ath5k surely don't use it.
@peti:
Thanx for your report. The problem with wifi/wlan and eval are fixed in svn. The fixes will be included in the next release.
@LemmingKing:
I fixed 1) and 2) in svn. As for 3), it will need more in depth testing. I did not try what you asked...
As for the madwifi, I added something in svn. The driver is now an array (for each devices), I crated a function similar to execute_command() but for (un)loading modules from an array. In the configuration file you can put as many modules in the drivers' arrays. Note that you can also put options, for example: ...DRIVERS=(... "pciehp pciehp_force=1" ...)
That should hellp you with the multiple madwifi modules.
And for the pciehp, I added a quirks for madwifi. Just uncomment "#WIFI_MADWIFI="yes" # Enable madwifi quirks?" so the script acpi-eeepc-generic-toggle-wifi.sh will execute the quirks (load/unload of pciehp) _after_ the toggle.
Ideally, I would like to remove the WIFI_MADWIFI="yes" flag, and put an autodetection. I don't know how to detect a madwifi driver/card though. Is "wlan" module only for madwifi? I never saw any of these modules so probably, but I played safe by putting the flag for the moment.
If that a satisfactory solution? I think it still keep the configurable options while preventing hacks with *_[PRE-POST]_[UP-DOWN]=() arrays.
Can you test it and report if it works?
eeepc-restore expects the WIFI state in a file called "wifi", but the toggling script actually uses a file called "wlan":
| --- a/rc.d/eeepc-restore
| +++ b/rc.d/eeepc-restore
| @@ -49,7 +49,7 @@ case "$1" in
| fi
|
| if [ "$RESTORE_WIFI" = "1" ]; then
| - if [ -e "$EEEPC_VAR/states/wifi" ]; then
| + if [ -e "$EEEPC_VAR/states/wlan" ]; then
| stat_busy "Restoring EeePC state (wifi)..."
| /etc/acpi/eeepc/acpi-eeepc-generic-toggle-wifi.sh restore
| stat_done
The calls to ${INTERFACE_UP} and ${INTERFACE_DOWN} in acpi-eeepc-generic-functions.sh need to be eval'ed for the output re-direction to work:
|--- a/acpi/eeepc/acpi-eeepc-generic-functions.sh
|+++ b/acpi/eeepc/acpi-eeepc-generic-functions.sh
|@@ -417,7 +417,7 @@ function device_on {
|
| if [ "x$INTERFACE" != "x" ]; then
| # Put interface up and wait 1 second
|- ${INTERFACE_UP}
|+ eval ${INTERFACE_UP}
| sleep 1
| fi
|
|@@ -476,7 +476,7 @@ function device_off {
|
| if [ "x$INTERFACE" != "x" ]; then
| # Put interface down and wait 1 second
|- ${INTERFACE_DOWN}
|+ eval ${INTERFACE_DOWN}
| sleep 1
| fi
|
Thanks for the great work!
Thanx for your report! Issues 1) and 2) are "historical": Before merging the toggle functions in a generic one, I had a lot of duplicated code. So fixing something somewhere needed to be "ported" to all other implementation. So some things might have slip-in. :) I'll fix this.
As for the third one... I would suggest opening an issue on google code. That way I can keep track of it. We could even add a wiki entry for madwifi info.
Hi big_gie, it's me again.
gave a try to this new version and found a couple of new (erm... actually, old) little things ;)
-- next two issues, I think, are to be corrected --
1) Not a bug, but...
You use /var/eeepc instead of defined for this place $EEEPC_VAR in some lines in acpi-eeepc-generic-functions.sh:
25:chmod a+w /var/eeepc/states/* &> /dev/null
203: cat /sys/class/backlight/eeepc/brightness > /var/eeepc/states/brightness
208: cat /var/eeepc/states/brightness > /sys/class/backlight/eeepc/brightness
219: previous_brightness=`cat /var/eeepc/states/brightness`
224: echo $actual_brightness > /var/eeepc/states/brightness
2) Restoring wifi state doesn't work.
You set NAME_SMALL="wlan" in acpi-eeepc-generic-toggle-wifi.sh and store state in the file with this name,
but restore data from "wifi" in /etc/rc.d/eeepc-restore
And you load state into variable SAVED_STATE, but use RADIO_SAVED_RADIO later
-- this issue, possibly, is my own. Also it is _rare_. But anyway, I decided to write about it here --
3) Very small issue. Really small. My device can't wake up properly when suspended in console mode (without X): display refuses to turn on. When X was started and killed, all is fine, but when X haven't been started at all - something goes wrong. This is _really_rare_ case, so this might be left as is without any harm. I will try to find a solution later, but I'm afraid, that my solution will work only on my device, so... it would be great if you tried to suspend/resume your eee before starting X.
-- finally, I remembered about some troubles with madwifi on/off configuration. I configured this a week ago and have totally forgotten about it --
The matter is that madwifi has some configuration quirks (found them in sources of the original deprecated acpi-eee900):
- madwifi has a set of modules, not a single one, so, loading/unloading them as a WIFI_DRIVER in your scripts don't work for me
- to wake madwifi up properly it is necessary to reload additional module pciehp with parameter pciehp_force=1 (loading must be done after loading all the other madwifi modules and rfkill'ing wifi)
To do this I entered the following in config (WIFI_DRIVER in my case may contain anything, it doesn't work anyway):
>> COMMANDS_WIFI_POST_DOWN=("sleep 1 && /sbin/modprobe -r wlan_tkip wlan_ccmp wlan_scan_sta ath_pci ath_rate_sample ath_hal wlan pciehp") # remove drivers and pciehp
>> COMMANDS_WIFI_PRE_UP=("/sbin/modprobe -a wlan_tkip wlan_ccmp wlan_scan_sta ath_pci ath_rate_sample ath_hal wlan") # load drivers with -a
>> COMMANDS_WIFI_POST_UP=("/sbin/modprobe pciehp pciehp_force=1") # load pciehp
This configuration works just fine, but is a little bit messy :)
I tried to edit scripts as to avoid this configuration hell while saving scripts' structure, but could not manage to get things working.
First of all, I edited scripts to accept multiple modules as WIFI_DRIVER. Didn't help: when unloading, some modules were left in memory (maybe they need to be removed after rfkill'ing the wifi). Anyway (un)loading is done _before_ rfkill'ing, but pciehp has to be loaded _after_ that.
So I tried moving (un)loading modules in your scripts after switching device on/off. That led to inexplicable errors with whole system (couldn't run apps or even shutdown my eee). I can't understand what was that, but tried a few times - nothing changed.
So, I think, this configuration is the simplest way to get madwifi turning on/off properly. But it surely is not obvious :)
It might be reasonable to add this to comments in the configuration file for people who also use madwifi drivers...
Well, that's all for now :) I think, the first two things should be corrected while all the other are mostly for your information...
Oh... It's too late already... sleep-sleep-sleep :)
Bye
Hi LemmingKing,
Thanx for the bug report. You are right. It is corrected in 0.9.1-1
Also, for the wifi toggling, this dates back to when I first bought my eee. In the first days the wifi button reported two events: one when the device was up, and another one when the device was down. But after a couple of days is stopped acting like that and always reported the same event! So I kept that "historic" feature just in case. It seems nobody tested the 900 configuration file before ;) This is fixed also in 0.9.1-1
Thanx for the report!
erm...
in previous message, speaking 'the "down" command seems to never be executed' I meant 'the "up" command is executed instead'
so, I just use it as the "toggle" command.
// probably, the acpid is responsible for this behaviour...
Hi,
found a possible bug in acpi-eeepc-generic-functions.sh in function "device_toggle":
I think, you should replace the line 297
>> if [ "${SYS_STATE}" = "1" ]; then
with
>> if [ "${IS_ENABLED}" = "yes" ]; then
my eeepc900 with madwifi-newhal-svn installed as wireless driver were refusing to turn wifi off until this line was changed.
Also, there is one another strange thing:
eeepc900 has two different events for switching wifi on and off. However, the "down" command seems to never be executed
Well, I don't think, that it is a bug in your package... Just a little strange fact :)
Oh, and thank you very-very much for this package - your work is really great! :)
Missing script included with 0.9.0-2
Sorry about these! I included the webcam script in svn.
But then I don't understand the error in the conf file. I just tested it and it works. I don't know why it complains about the > when it is part of the string (double quoted).
diego@arch eeepc>sudo ./acpi-eeepc-generic-suspend2ram.sh
/etc/conf.d/acpi-eeepc-generic.conf: line 182: syntax error near unexpected token `>'
/etc/conf.d/acpi-eeepc-generic.conf: line 182: `SUSPEND2RAM_COMMANDS=("echo -n \"mem\" > /sys/power/state") # Simple suspend'
There isn't the file for the webcam in /etc/acpi/eeepc/
These are my fist impression, then the bluetooth and the wifi toggle right!
Other things I haven't yet tryed....
However, You've made a great work! Always better...Compliments!
Great news to all! New version is out. What's new:
-Licensed to GPL3
-New model supported: 1000HE
-Webcam toggling script
-Unification of wifi, bluetooth and webcam toggle script
-Refactoring of some devices (wifi & bluetooth) status detection
-New toggling script (acpi-eeepc-generic-toggle-displays.sh) to switch between laptop screen only, external monitor clone, external monitor right/left/above/under of laptop screen (configurable) and external monitor only. You can comment any of these in the script (see line 61) if you want to disable any of them.
Please report back if it works of if you have issues with it!
:)
Good news to all also: I was able to write the script to toggle through different display settings:
-Just LVDS (laptop screen)
-Clone VGA-LVDS
-VGA left/right/above/under LVDS (configurable)
-Just VGA
To anybody who would like this feature, please test the latest svn version (branch 0.9).
Good news big_gie!!!
Now the last thing that this script needs is the toggle of performance build in....
You're making a really good work!
Waiting with impatience this 0.9 release :D
Hi all, I will release 0.9.0 soon. See the svn log or the homepage for the full changelog.
Here is the main things:
-Changed to GPL3
-Added a script to toggle webcam
-Unification of wifi, bluetooth and webcam toggle script.
-Refactoring of some (wifi & bluetooth) devices status detection
-New model supported: 1000HE
Please test and report back :)
Hi.
I see a little problem with toggle wifi.
This problem is vvery small and i write for help you with this script, that is almost perfect.
The probllem is that when i turn on the pc and the wireless is turn off and i press Fn+F2 the wifi is turn on without notify for 1 second, and after write turn off in notify and the wifi is turning off, and after work perfect without problem.
I hope that you understand this little problem.
Wifi tuurining off also if is just turn off, but only the first time, because after work without problem.
Bye Bye
I solved my problem a few posts down :
I had xfce4-power-manager running, and it intercepts Fn+F1. As such, I have to manually set inside xfce4-power-manager that I wish Fn+F1 to translate into "sleep".
For the problem of the switch monitor no problem, for this i can wait that you will complete this.
The script is very good, is the best script for eeepc on archlinux and work very good!
That's out of my control is lxrandr does not work for you...
It's pretty hard to parse the output of xrandr...
lxrandr doesn't work to me!
Later i try other graphical package, but i remember that a little time ago work also the switch monitor, but now doesn't work, but is the unique problem, because now work all almost correct!
This script if far from complete. I'm still working on it. See issue #20 (http:// code.google.com/p/acpi-eeepc-generic/issues/detail?id=20 )
Use something else until then. Here are some graphical suggestions:
urandr http://aur.archlinux.org/packages.php?ID=14010
arandr http://aur.archlinux.org/packages.php?ID=17385
lxrandr http://aur.archlinux.org/packages.php?ID=18289
The unique problem is the switch monitor with xandr or acpi-eeepc-generic-toggle-displays.sh that in this version there isn't!
This is the unique problem at the moment.
Thank you and congratulations
Finally with kernel26-eee901 work perfect your script.
I apply a patch for eeepc-laptop for kernel and a patch found in issue 14 for fix bluetooth!
Now is all perfetct! Congratulation for the work, very good, this is the definitive script for all eeepc models!
Thank you for your work
With kernel26-eee901 the key doesn't give nothing result!!
Do you have idea?
Why does't work with these kernel?
@marco_eeepc & nexonic:
Have you remove/comment out this line in /etc/conf.d/acpi-eeepc-generic.conf?
EEEPC_CONF_DONE="no"
You need to comment out or remove that line in order to stop the message (oh, and you guys should read the entire config file :-) ).
However this script doesn't work with kernel26-eee901, in dmesg appear some error:
[ 4.365449] eeepc: Eee PC Hotkey Driver
[ 4.366682] eeepc: Hotkey init flags 0x41
[ 4.366873] eeepc: Get control methods supported: 0x101713
[ 4.367105] input: Asus EeePC extra buttons as /devices/virtual/input/input7
[ 4.775095] ACPI: EC: missing confirmations, switch off interrupt mode.
[ 5.276169] ACPI Exception (evregion-0422): AE_TIME, Returned by Handler for [EmbeddedControl] [20081204]
[ 5.276200] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SBRG.EC0_.BST2] (Node f7812dc8), AE_TIME
[ 5.276295] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.CBST] (Node f7815498), AE_TIME
[ 5.276360] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node f78153d8), AE_TIME
[ 5.276432] ACPI Exception (battery-0382): AE_TIME, Evaluating _BST [20081204]
Why appear all this error?
ACPI script doesn't work, only if i launch manually the script
I have edited the file but always appear these sentences, i don't understand because says always "PLEASE EDIT YOUR CONFIGURATION FILE: ..."
@zodmaner I'm glad you are happy with it ;)
To all who have problems, please report your problem on the issue page @ http://code.google.com/p/acpi-eeepc-generic/issues/list so I can keep track of them. As I'm quite busy, I can't work too often on this and solve problems when they appear. Using the issue page is the best way :)
As for the message saying to edit the file, have you guys... well... edited the file?? You have to, as the message states.
Hi,
have the same problem as marco_eeepc with the notify "PLEASE EDIT YOUR CONFIGURATION FILE: /etc/conf.d/acpi-eeepc-generic.conf".
Finally haved time to try out this package on my Eee PC 901. Everything is working like a charm. Thank you big_pie for your time and effort. :)
Hello
I want to notify a problem very fastidious:
When i press a key in the screen appear a lot of notify "EDIT THE FILE: "..." a lot of time!!
Is very very fastidious, how can i resolve this problem?
Other problem is that with KDE doesn't work correct audio with script!
Because before control by KDE and after by script, i think that is so, but i don't sure.
Hello.
When I manually execute
sudo /etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh
or when I bind it to some other hotkey (for ex: COMMANDS_BUTTON_RESOLUTION), it works fine and the eeePC successfully enters suspend.
However, I cannot make the Fn+F1 combination work.
COMMANDS_SLEEP=("/etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh")
=> simply doesn't do anything.
It's rather odd... I checked with acpi_listen, and the Fn+F1 combo returns "00000080", just as indicated on acpi-eeepc-901-events.conf
I am on the 901, running Blind's kernel26-eee901 + XFCE 4.6.
For the same events when wifi is on and off I think its a normal thing. I kept the possibility of reacting to different events in the script, but its always the same event.
Maybe you could open an issue on the google code page so I can track the problem?
All the events seem to be the same between the 1000H and the 904H. I fixed my volume problem (change the variable ALSA_MAIN_MIXER from "PCM" to "LineOut"), but the wifi toggle will not turn the wifi back on. I'm using the ath5k driver for wifi, so i changed the "WIFI_DRIVER" variable. It seems that rfkill isn't correctly saving the state of my wifi, because wether or not the wifi is on or off, i always get the "00000010" event instead of the "00000011" event
The conf file for each model only contain match of acpi events.
So what I suggest is to uncomment "KEY_SHOW=1" in /etc/conf.d/acpi-eeepc-generic.conf and press each keys. It should show you what is the event for each key press. Now copy the 1000H file to a 904HA and make sure the events generated matches the one of the file. Then send it to me I'll include it.
As for the wifi toggle not working, it might be something different. Make sure first that the events are the same. We'll see for the rest after :)
Which conf file should I be using for a 904HA? The hardware is suppose to be almost identical to the 1000H, but it doesn't seem like it's working (wifi LED will go on/off, but wireless will not come back from disabled state, volume doesn't seem to work)
I'll adapt the conf for the S101, thanx for suggestions ;)
As for the Fn+F7/Silver2, you should set what it Fn+F7 does in the conf file, not in the model file...
So if you want Fn+F7 to toggle touchpad, make sure the event generated by Fn+F7 is "00000016" (KEY_Fn_F7="00000016") and map the "screen off" key to the toggle script:
COMMANDS_SCREEN_OFF=("/etc/acpi/eeepc/acpi-eeepc-generic-toggle-touchpad.sh")
in the configuration file.
suggestion modify on :/etc/acpi/eeepc/models/acpi-eeepc-S101-events.conf
#S101 only have one silver key above F1,F2. In windows, it toggle power saving mode, i set to blank screen only
KEY_SILVER1="00000039" # Blank
# I set the Fn_F7 to toggle touchpad on/off
KEY_SILVER2="00000016" # Change resolution
# disable the original general eeepc Fn_F7
KEY_Fn_F7="00000000" # ???
I found I can't use notification-daemon OSD, it generate signal 6 when I presss 'Preview' on notification-properties
New version: 0.8.2-1
Changelog:
-Fix AC plug/unplug events on 1000H (see http://code.google.com/p/acpi-eeepc-generic/issues/detail?id=13 )
New version: 0.8.1-1
Changelog:
-Fix: acpid-ted1 reports different events then extra/acpid (power button, sleep button)
-Removed everything /proc/acpi (which is deprecated) related (except lid state, still not ported to /sys)
-Small fix in wifi toggle
-Better user autodetection. Should be more reliable
-Small fixes and cleanups
No sorry, this script is only the acpi part, not the graphical one. The script calls libnotify, which is a generic OSD provided by the package notification-daemon. I also included support to call knotify or dzen.
When I first tried to adapt an acpi package from 901 to 1000, I had to play with asus-osd. And it was crappy. It was not consistent. It was called by acpid, but it was also listening to acpi events! It was controlling the sound, which is shouldn't since its an OSD. The source is available, but then it is hidden inside a 2.7 GB file on a freaking slow ftp server. It took me more than a month just to download it.
So for all these reasons, and many more, asus-osd is a no go for me. If you have the courage to package it and strip everything non osd related, then I might include include support for it, like I did for knotify or libnotify.
Would it be possible to provide asus-osd as an option please?
Thanx for your report! Glad everything else works...
As for the wireless thing, I have the same problem. I think it might be something kernel related. Can you open an issue on the homepage so I can keep track of it? Just copy paste your post, you gave all the information needed ;)
really nice scripts
i've got a little problem with the networkmanager.
when i switch the wlan-device off, everything works fine. the "Wireless Networks" dissapear in the nm-applet. when i switch wlan back on, the menu-entry "Wireless Networks" appears again, but it doesn't find any networks :(
with wicd it's the same... switching off -> fine ... switching on -> no wlans are found
manual loading of the rt2860 module doesn't solve the problem. i also tried to restart the wicd / networkmanager daemons withouth success
the only thing thats a bit weird is, that if i try "ifconfig ra0 up" it says "SIOCSIFFLAGS: Operation not permitted" - but i think that's only because the nic is already up again. networkmanager even recognizes it ("Wireless Networks" entry in the menu) - but it can't find any networks.
Configuration:
EEE 1000H
Up-To-Date Packages (DE: Gnome)
Stock Kernel 2.6.28-ARCH, drivers for wlan are the rt2860 from AUR with a modified pkgbuild, so that they are installed as "rt2860sta"
and i think i did all the configuration that is needed in acpi-eeepc-generic.conf
btw. everything else works like a charm :)
New version: 0.8.0-1
Changelog:
-Wifi toggle events corrected for 901 and 900A
-Updated and fixed user autodetection
-Execute command as user by putting a "@" in front of the command in the configuration file
-Don't do anything nor notify if volume is at 100% and volume up is pressed. Same thing for 0% and volume down, and same thing for brightness too.
-Execute "xhost +" and "xhost -" before and after a key press.
-More verbose KEYSHOW
-Work began on automatic display toggle using xrandr
-Before restoring touchpad, check if X is running
-Hide cursor when disabling cursor (needs "unclutter" from AUR)
-Refactoring of wifi and bluetooth toggle. Mainly simpler if/then/else
-Many small fixes
When i try to toggle wifi with the Fn+F2 key it doesn't work. When i
uncomment showkey, just say: "you pressed key #10". I'm using the last
kernel 2.6.28.
bash-3.2# /etc/acpi/eeepc/acpi-eeepc-generic-toggle-wifi.sh debug
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): Wifi rfkill: /sys/class/rfkill/rfkill0/state
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): Wifi state: 0
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): Wifi interface:
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): Wifi module: rt2860sta
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): COMMANDS_WIFI_PRE_UP:
NONE
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): COMMANDS_WIFI_POST_UP:
#1:
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): COMMANDS_WIFI_PRE_DOWN:
#1:
DEBUG (acpi-eeepc-generic-toggle-wifi.sh): COMMANDS_WIFI_POST_DOWN:
NONE
bash-3.2#
Well mayne networkmanager does not need any post/pre commands. Have you tried it? What would you think it needs as pre/post, if any?
Is anyone using network-manager 0.7 with this package? I'm wondering what the commands would look like for:
COMMANDS_WIFI_POST_UP
COMMANDS_WIFI_PRE_DOWN
With original kernel the problem with audio that you have closed is still remain!
The mute doesn't work correct, and the volume up and down doesn't work correct.
You told me that the problem was my kernel, but with kernel original precompiled kernel26 2.6.28-ARCH doesn't work however.
Can you answer my question please?
New version: 0.7.0-2
Changelog:
-Fixed md5sum
I removed 3 patch in my kernel, and now doesn't work wireless, and the volume always egual.
I want to do a question on your kernel:
If you use stockk kernel 2.6.28 for bluetooth what do you do?
How to apply the patch and which?
And for rt2860 that in 2.6.28 there isn.t?
And what do yo use of file config for kernel?
Thanks
Sorry for my english, however in the last version toggle bluetooth doesn't work correct because it tried always turn on, also if is just turn on.
Audio there are problem with volume up and volume down, same problem that i write in issue with Audio.
Correct md5sum as of 0.7.0-1 is d75382c9b393f780d0a50ccaaf8521cf.
I'm sorry I have trouble understanding your English... Let's continue this on the issue page.
With new version, work correct wireless, standy, blank screen, change resolution, brightness, switch monitor (more or less), system monitor, but doesn't work correct bluetooth, because turn on, but then doesn't off because write always bluetooth turning on, and then is set up bluetooth key in F7, and i put also in silver key 3, and then audio doesn't work correct, mute if i modify a line, but volume up and volume down to do 2 time!!
Bye
acpi-eeepc-generic.conf doesn't pass the md5sum ;)
New version: 0.7.0
Changelog:
-New restore feature: you can restore hardware states on boot with "eeepc-restore" in your DAEMONS array. Support wifi, bluetooth, brightness and touchpad (touchpad might not work)
-Refactoring of OSD functions
-New OSD possibility: dzen2
-New suspension lock: execute that script and it will toggle a lock, preventing suspension from happening. There is a .desktop file for it too.
-External monitor toggling script
Today i try also eee-control, that for me is incompllete. It haven't switch monitor, rotate lvds, change resolutons.
But the wireless and bluetooth toggle correct, but i think a thing.
Maybe the problem is my kernel, because have a control Fn Key integrated in kernel, and eee-control maybe use these, and your script use a different method.
What do you think?
You think that can to be conflicts?
New version: 0.6.3-1
Changelog:
-Mainly fixes
-New acpi event for 'processor' (prevents OSD when waking up)
-bluetooth icon
-test for deprecated radio control just in case
-OSD display of suspend blacklisted processes
Thank you, now the change resolution work.
For other problem i write in homepage.
Thanks again
@marco_eeepc:
Just put:
COMMANDS_BUTTON_??????=("/etc/acpi/eeepc/acpi-eeepc-generic-toggle-resolution.sh")
for whatever button you want to change the resolution. This script will toggle through all available resolutions of your laptop screen.
Thank you, i see the configuration file, but i don't know what do i put for change resolution, is util for me when i use ann external monitor, because with these key i return to normal resolution.
Thank you, i hope that the problem will be resolve very soon...
For now i'm happy because this script is make good
@marco_eeepc:
"Silver Key 2 for resolution Blank Monitor"
That's not a problem!!! Look in the configuration file!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
"Second Problem:"
Could you open an issue on the homepage issues list (http://code.google.com/p/acpi-eeepc-generic/issues/list) by clicking here: http://code.google.com/p/acpi-eeepc-generic/issues/entry please?
"Third Problem:"
Again, could you open another issue here http://code.google.com/p/acpi-eeepc-generic/issues/list please?
PLEASE PLEASE PLEASE use the homepage to report your problem by clicking on "New Issue" on the top left corner of this page: http://code.google.com/p/acpi-eeepc-generic/issues/list I wont be correcting any other problem posted here.
Now work correct, but there are some problem with this script:
First Problem:
Silver Key 2 for resolution Blank Monitor
Second Problem:
Wireless and Bluetooth doesn't toggle correctly
If bluetooth is just enable, then is not turn off, but in notify write always that could not turn on bluetooth, for wireless is egual!
Third Problem:
The UnMute, Volume Up and Volume Down doen't work correctly
UnMute doen't mute iSpeaker, and in script is write "amixer Lineout and "amixer iSpeaker" but the speaker doesn't mute.
Volume Up to 11% and not 5%, volume down also.
The notify for volume is not correct, because the result is this:
UnMute (100%)
Volume Up (100%)
Volume Down (100%)
However this is a report of problem for now, and i want that this script will be the best, because i like and is very good.
I hope that with my report in future this script will be perfect, congratulations for work, because in little week this script work very good!
Thanks for all
I see that in my kernel is not set PROC_ACPI_EVENT.
You think that with these option work all correct?
Thanks
I have problem with this script, i like this script, but for now not work correctly.
The bluetooth and wireless are turn on, but says that their could't turn on, but after doesn't turn off!
Other problem is that if i press a keys doesn't response, and missing /proc/acpi/event and the script acpid doesn't work!
@marco_eeepc:
"it needs only some adjustment and some fix."
Please change the configuration file to your needs. If you think your modifications can help others, please let me know.
New version: 0.6.2-1
Changelog:
-Fix CPU autodetection
-Added --no-desktop to pcmanfm
-Print warning if shm is disabled
-Display warning for 20sec if user has not reviewed the configuration file
-Fix OSD notify for certain key press (power, suspend)
-Fix suspend's processes blacklist check
I have a problem with script...with kernel26-eee901 wireless toggle correct, with 2.6.28-ARCH i installed with yaourt the package rt2860, but doesn't work!!
The problem is the wireless i think, and not the script, in kdialog write "Could Wifi Off" or same.
The bluetooth i will try to apply the patch, and then in kdialog with volum write always 100% and volume up and down is not correct, in configuration file is write 5+ and 5-, but really up and down 11+ e 11-, more or less.
Thanks for all, this script i think that is the best, it needs only some adjustment and some fix.
eeepc.desktop: Uses gksu to edit the configuration file (/etc/conf.d/acpi-eeepc-generic.conf)
Kdialog is effectively used as a KDE OSD here. Only drawback is that it cannot display an icon, something libnotify can.
The script should work with 2.6.28-ARCH. But then there is some bugs with bluetooth on 2.6.28. See here for the patch if you are courageous enough: http://code.google.com/p/acpi-eeepc-generic/wiki/Bluetooth
Without these 2 patches, you might see "echo: write error: No such device". That's "normal"...
You can configure all keyboards in /etc/conf.d/acpi-eeepc-generic.conf PLEASE EDIT THAT FILE!!!
The last question: eeepc.desktop what is it?
I didn't find a script gui for configuration...
KDialog is a notify for KDE? Very interesting, however i see that the problem with bluetooth depend by kernel26-eee901 in aur, bacause doesn't work never!
With 0.5.1 toggle wireless and bluetooth correct.
Now i reinstall arch, but you think that with a original kernel 2.6.28-ARCH without modify, your script work correct?
I want this: F1: Standby; F2: Toogle wireless; F3: Nothing; F4: Nothing; F5: Bightness Down; F6: Brightness UP; F7: ?; F8: Switch Screen (Only VGA, Only LVDS, Both); F9: Task Manager; F10: Mute; F11: Volume Down; F12: Volume Up; Silver Key 1: Blank Screen; Silver Key 2: Change Resolution; Silver Key 3 or 4: Toggle Bluetooth.
And then i want the notification in KDE.
This script work so in future?
Now i see that some function work perfect, for now great work.
New version: 0.6-1
Changelog:
-A lot of bluetooth fix
-Possibility to use "kdialog" instead of libnotify. This also opens the door to many different OSD.
I have a little problem: i try in this moment your script, but the keys don't work, but wireless now toggle with command in terminal.
I try to launch acpid but the result is this:
[root@arch-laptop marco]# /etc/rc.d/acpid start
:: Starting acpid [BUSY]acpid: can't open /proc/acpi/event: No such file or directory
[FAIL]
How can i resolve this problem?
However with other kernel work the key function, now donesn't work, you what do you suggest for a kernel to use my eeepc without problem?
I put a kernel hacked by aur, exactly kernel26-eee901 for a best support for my eeepc 1000h, but, you try kernel 2.6.28.1 vanilla original and work however this script and all work?
Because i want use the original kernel, but i don't know if needs some support.
For wireless i can intall rt2860 by aur, and needs other module or some modify?
I will try your new script just i can
New version: 0.5-1
Changelog:
-Initial support for bluetooth toggling. Please test and report!
New version: 0.4-1
Changelog:
-Changed 'toggle' script's name
-Added a touchpad toggle
-Added a resolution toggle script
-Refactoring of the get_model function
-No need anymore to source the configuration file, only the function file
@marco_eeepc:
I don't understand what the problem is. Could you install the latest version, and post a detailed report of the issue here http://code.google.com/p/acpi-eeepc-generic/issues/entry please?
That way, I could track what is wrong.
Thanx
The problem that i write some day ago now are correct or also doesn't correct?
New version: 0.3.3.1-1
Changelog:
-Corrected a bug where XUSER was still used instead of user.
New version: 0.3.3-1
Changelog:
-Default to just shut down screen when lid close on AC
-New user autodection
-More information/comments for users in the configuration file and at installation.
-New debug for wifi. As root, execute this:
/etc/acpi/eeepc/acpi-eeepc-generic-wifi-toggle.sh debug
It should print some info that you can paste if there is a problem. It should also show a window with text "Can you see this?". If you do, then the OSD should work.
I installed 0.3.2-2. I already fix the driver problem i "makepkg" with
driver rt2869sta and your right now works.
I didn't understand the other part. What i have to change on the scripts
to make the keys Fn+F2 work ?
And osd ?
The output of the command /etc/acpi/eeepc/acpi-eeepc-generic-wifi-
toggle.sh is:
r = rfkill0
r = rfkill1
execute_commands #0: pkill wicd-client
execute_commands #1: /etc/rc.d/wicd stop
execute_commands #2: pkill wpa_supplicant
execute_commands #3: pkill dhcpd
/bin/stty: default input channel(this is a translation from portuguese)
(stdin): Inappropriate ioctl for device
:: Stopping wicd Daemon 9G [BUSY] 9G (DONE)
The same command but using user:
Couldnt get a file descriptor referring to the console
r = rfkill0
r = rfkill1
Password(translation):
The othe functions work exept Fn+F6 (AP), i think that should work with
htop that i have installed. The first hotkey turns off the monitors both
in the other acpi just turn off lcd on eee. The 2nd key does the same,
turns off the monitors. The other 2 don't work. Suspend2ram works very
well. When i close the lid it turns suspend2ram is it possible to change
that on AC ?
At the moment, still doesn't works in my eeepc 1000h
New home for the project:
http://code.google.com/p/acpi-eeepc-generic/
From now on, please report problems about the scripts there. Continue to report packaging (PKGBUILD) problems here.
You can check out the code by svn:
http://code.google.com/p/acpi-eeepc-generic/source/browse/#svn/trunk
@amadlopes:
Are you using rt2860 1.8.0.0-1 from http://aur.archlinux.org/packages.php?ID=14557 ? If you look at the PKGBUILD, you'll see it install the driver to "rt2860.ko" instead of "rt2860sta.ko". But the driver's name is really rt2860sta. Because of this you might have trouble modprobing it in/out. But if it works by just changing the config file then its fine...
As for the root problem, it probably comes from the "su" command executed in acpi-eeepc-generic-functions.sh (see functions eeepc_notify or execute_commands_as_user). You can't run "su" as normal user. You need to be root. So the script needs to be executed by root. If the script is executed by acpid, then its fine. If you just try to run the script yourself it wont work.
As for the OSD, if you just execute the script yourself it wont work because it think it is root and tries to call "su". So execute the script with root priviledges. What can be wrong also is the "xhost". Type "xhost +" in a terminal and try again.
@marco_eeepc:
I'm sorry I'm out of idea. "Does not work" does not help me find the problem. This is still experimental and I am still fixing things. So please look at the script yourself to see where it fails.
New version: 0.3.2-1
Changelog:
-Wifi/Bluetooth toggle: verify if rfkill switch really exist before access
-Fix md5dums
Nothing!! Doesn't work!
I try also to enable bluetooth and wifi in bios but nothing, doesn't work!
I have a 1000H, and with acpi-eee901 by robertek work correct, with this doesn't work.
First it didn't worked, i had to connfig /etc/conf.d/acpi-eeepc-generic.conf WIFI_DRIVER="rt2860" (was rt2869sta). But only works with root. With normal user ask for password and dosn't accept any pass root or user. I don't use sudo but the user is part of network group. I don't see any osd is it normal ? Tomorow i'll try the new release 0.3.1-1 Thanks for the great work.
The fix doesn't install:
acpi-eeepc-generic-wifi-toggle.sh ... NOT VERIFY
But the first time the bluetooth and wifi must to be active in bios?
Now try the fix and to enable in bios and to give you.
New version: 0.3.1-1
Changelog:
-Wifi toggle: Don't fail if rfkill switch does not exist
@amadlopes:
"Do i have to config anything?"
Have you look at the file /etc/conf.d/acpi-eeepc-generic.conf? All the configuration is done there.
Try executing the wifi toggle as root:
sudo /etc/acpi/eeepc/acpi-eeepc-generic-wifi-toggle.sh
and see/report any problem it might give.
@marco_eeepc:
"Those command doesn't give result...."
This is weird... if you have the rfkill module loaded, it should expose the eee's switch in /sys/class/rfkill/... I'll update the script to fallback if it does not find the switch.
Have you checked in your bios if wifi is enabled?
I installed the package on my 901 with kernel 2.6.28.1-1 but the wifi doesn't turn off. Output of: ls /sys/class/rfkill "rfkill0 rfkill1". On boot i don't get any errors, rfkill and eeepc_laptop are on modules. Do i have to config anything ?
Those command doesn't give result....
How can i resolve this problem?
But i see that you add the support for bluetooth, because doesn't work?
Thaks for answer and support
Could you post the result of "ls /sys/class/rfkill/" please?
"The module eeepc_laptop doesn't exist because is compiled on the kernel"
Thats perfect...
"bluetooth doesn't turn on"
Its not really implemented yet.
"wireless is egual, doesn't turn on."
Thats because the script fails to check the rfkill switch which cancel the execution of the toggling...
I writte "modprobe rfkill" and after with wifi give me this result:
/etc/acpi/eeepc/acpi-eeepc-generic-wifi-toggle.sh: line 46: /sys/class/rfkill/rfkill0/state: No such file or directory
The module eeepc_laptop doesn't exist because is compiled on the kernel: EEPC_LAPTOP=y
The bluetooth doesn't turn on, and wireless is egual, doesn't turn on.
The file /sys/class/rfkill/rfkill0/state is "generated" by the kernel module "rfkill". Please load it with "modprobe rfkill" and/or put it in your /etc/rc.conf file:
MODULES=(... eeepc_laptop rfkill ...)
I try but there are problems with wifi and bluetooth.
As root i try launch 2 command, but wifi give an error:
ls: impossibile accedere a /sys/class/rfkill/: No such file or directory
/etc/acpi/eeepc/acpi-eeepc-generic-wifi-toggle.sh: line 46: /sys/class/rfkill/rfkill0/state: No such file or directory
Bluetooth doesn't give error, but doesn't work, not turn on.
Ok thanx for your feedback.
The reason why "user1" and "user2" might not be working for wifi/bluetooth toggle is that these commands are executed as _user_ and not as root. You can add "sudo" in from of the command if you whant root access to enable/disable a card. Fn+F2 on the 1000* launches the command "/etc/acpi/eeepc/acpi-eeepc-generic-wifi-toggle.sh" as root
The 1000 and 1000H are very similiar, the card is rt2860, the bluetooth doesn't works, i put the command for turn on bluetooth in user 1 in the third silver key, and is not turn on, the same for wireless, is not turn on.
I have a 1000H, the volume is mute correcct, the screen is blank correctm the luminosity workk correct, and system monitor and rotate monitor also.
The external monitor and screen resolution still i don't try, for now only bluetooth and wireless doesn't work, i try to reboot a system and after i tell you if work.
I don't mind helping you, but I'll need more information then just "it does not work" :P Give me at least your model number...
"wireless is not turn on"
What do you mean? That you can't connect to a website on boot? On that the toggling (putting it on/off) does not work? What is your card? Is it a different model then the rt2860 found in the 1000? If so its normal that the script does not work: you need to edit the configuration file and put which driver you are using so it can load/unload it.
"kde don't see notifications"
You mean that when you are inside KDE and press keys you don't see a notification about it? Is it only the notifications or that the commands are not executed as well? I mean, if you press the volume mute combination, does it really mute? I think of two possible culprit:
1) User autodetection fails. Try typing in a terminal:
. /etc/acpi/eeepc/acpi-eeepc-generic-functions.sh
echo $user
The "echo" should show you which user has been detected. If autodectection fails, it should fallback to the "XUSER" which is set in /etc/conf.d/acpi-eeepc-generic.conf Edit that file and change XUSER=... with your user.
2) Access control to your X server is enabled, preventing anybody, including root, to connect to it. Type in a terminal:
xhost +
And try again your keys.
I installed this package, but the wireless is not turn on, don't work, and in kde don't see notifications, while the asusosd work almost perfect!
Can you help me?
"I also don't work this, but you think that work with a zen-eee kernel, or kernel26-eee or other kernel? Original or not?"
This script only depends on "eeepc_laptop" kernel module, which should be present in all kernels (it is included in the vanilla and with Arch's kernel26 package). Maybe zen adds the "acpi_asus" module, or something like this, which might conflict with "eeepc_laptop". Please try it as I don't have the zen kernel.
"I want to pass to ext4 in my archlinux, and i want to put a kernel for eeepc 2.6.28 or up, do you think that this script with 1000H work?"
I have 2.6.28.1 running fine on my 10000. I formated the 32GB SSD drive with ext4 and no problem (might be more tricky to put ext4 on /). Arch's default kernel "kernel26" should work.
"how can i turn on/off bluetooth in user 1 silver key?"
Edit the file /etc/conf.d/acpi-eeepc-generic.conf and go around line 25. You'll see "COMMANDS_BUTTON_USER1", "COMMANDS_BUTTON_USER2" and such. Configure them as your liking. Put as many commands you want between the parenthesis and double quotes: ("command 1" "command 2" ...) Right now as I said I don't know what you mean by "how to toggle bluetooth". Do you have a script to shutdown bluetooth that you could give me? Take a look at acpi-eeepc-generic-bluetooth-toggle.sh Maybe you can edit it and tell me what you want in it?
"And then i can use without problem with KDE?"
KDE should not depend on any of my work.
I want to do another question, how can i turn on/off bluetooth in user 1 silver key?
And then i can use without problem with KDE?
Thanks
I see that you add the support for bluetooth, that's good.
I also don't work this, but you think that work with a zen-eee kernel, or kernel26-eee or other kernel? Original or not?
I want to pass to ext4 in my archlinux, and i want to put a kernel for eeepc 2.6.28 or up, do you think that this script with 1000H work?
New version: 0.3-3
Changelog:
-Added a conflicts=() array to prevent installation with other ACPI packages from AUR.
New version: 0.3-2
Changelog:
-More information on install/upgrade
New version: 0.3-1
Changelog:
-Import/Fix of some ACPI events from other packages for models other then the 1000
-I started working on bluetooth support. I just don't know how it works.
OSD is provided by "libnotify". I did not liked the asusosd: it was taking to much CPU for nothing...
As for bluetooth there is nothing (yet) concerning bluetooth. There is no key relating to this (at least on models I saw). But it is possible to bind a certain key to execute something to toggle bluetooth. I'll look into it.
As for the kernel, all features of this package should be provided by a vanilla kernel. You don't need zen. I know there was a kernel module that exposed some features of the Eee but I think this module is deprecated. So you need to patch your kernel (maybe zen is doing it). I use "eeepc_laptop" and "rfkill" module only which are part of vanilla kernel. So you don't need zen. I should try if it works on zen though.
I would say try it and report back if it works. Or if it does not, what exactly does not work so I can fix it.
New version: 0.2-4
Changelog:
-Forgot dmidecode dependency
I want to do a question: The bluetooth?
I don't see a bluetooth function in this script
I used acpi-eee901 on 1000H with a zen kernel.
Now with this script is possible use acpi-eeepc-generic without zen kernel with all the function and osd screen?
Thank you for answer
New version: 0.2
Changelog:
-Backup of the right file (etc/conf.d/acpi-eeepc-generic.conf)
-New model supported: 700, 701, 900, 900A, 901, 904HD, S101, 1000, 1000H, 1000HD
Please try on models other than 1000 as I only have this one.
New version: 0.1.1
Changelog:
-A forgoten "exit 0" prevented the script "acpi-eeepc-generic-suspend2ram.sh" to suspend.
This is an attempt to merge all acpi/eeepc related packages from AUR. It will not depend on the model: all model's acpi events will eventually be merged.
The included scripts have been written by others, but I modified them a lot. Thanx to:
http://eeepc-acpi-util.sourceforge.net/
http://aur.archlinux.org/packages.php?ID=22986
http://aur.archlinux.org/packages.php?ID=19036
Note that I only owns a 1000, so I only included its events. I will include more latter.
Features:
-Model agnostic. Create a "acpi-eeepc-MODEL-events.conf" file to support your model;
-Create package, install, use;
-Uses libnotify for OSD;
-Allow multiple commands, using bash arrays, for button pressed;
-Uses the features of vanilla kernel: no need for external patches;
-Wifi toggle;
-Rotate screen;
-Suspend to ram;
TODO:
-Include all eeepc's acpi events;
-Include "restore" functionality from eeepc-acpi-utilities (http://eeepc-acpi-util.sourceforge.net/).
v1.6.0