Asus EEE PC 1000HE
Incidentally, I've noticed it being much easier just to say 'triple-E', although it sounds silly, than try to say 'e pea sea', or even worse, 'e~e pea sea'.
Been doing some hacking away at Ubuntu 9.04 ("Jaunty")'s Netbook Remix. With the initial installation, my wireless didn't work; luckily, the wired ethernet did, and I was able to update (using aptitude, because apt-get was confused by the switch from the generic linux kernel packages to the specifically-versioned ones) and get the wireless working. nm-applet is surprisingly nonbroken these days, and keeps the static IP for my home wireless information stashed away completely distinctly from the configuration for 'whichever wireless AP you can find', which means I can just login (I'm not sure if nm-applet has to be running or if NetworkManager proper isn't keeping up) and have wireless connectivity at home or wherever without any futzing. (This is a big improvement over the NetworkManager/interface for the OLPC, for which I was doing command-line tweaks and rebooting. It's also an improvement over the Windows side of things, which insists on timing out on DHCP before "falling back" to the static IP information for home WAP. I'm worried it'll "fall back" to my home WAP's static IP if it can't a DHCP server on some other WAP...) The sound works, although the OSS mixer emulator doesn't seem to work. (This is an issue because I prefer to use WindowMaker, and I think all of its Dock mixers are OSS.)
Anyway, I got the wireless toggling working. The key thing to realize is that all the documentation you'll find online is wrong. :) For my 1000HE and installation of UNR 9.04:
1) In /boot/grub/menu.lst, add pciehp.pciehp_force=1 pciehp.pciehp_poll_mode=1 to the end of the first kernel. This will permit the wireless driver to find the card after you power-cycle it.
2) The following two scripts do things in the right order.
#!/bin/bash
# Turn the WiFi radio on.
echo 1 > /sys/class/rfkill/rfkill0/state
sleep 1
modprobe rt2860sta
#!/bin/bash
# Turn the WiFi radio off.
ifconfig ra0 down
rmmod rt2860sta
sleep 1
echo 0 > /sys/class/rfkill/rfkill0/state
Which rfkill control to use seems to be a stable mapping. (Where 'rkfill1' is the BlueTooth radio.) The scripts are deliberately asymmetric with respect to ifconfig; I don't know why (since I stole the ordering from eeepc-acpi-utilities, which, depending on the phase of the moon, break either the sound or the wifi), but they seem to work. My guess is that turning off the interface is a little rude than removing the module. (It's also entirely possible that a live network interface would prevent the module from being removed.)
It turns out that acpid actually scans /etc/acpi/events for matching events (keystroke-equivalents, usually), so you can readily set up your own mappings. If you kill acpid (sudo /etc/init.d/acpid stop) and then run sudo acpid --debug, you can easily see which keys acpid is seeing when you press them. I used that to make the following changes in /etc/acpi:
Change /etc/acpi/asus-brn-up and asus-brn-up to
#!/bin/sh
test -f /usr/share/acpi-support/key-constants || exit 0
. /usr/share/acpi-support/key-constants
acpi_fakekey $KEY_BRIGHTNESSUP
with the last line ending in $KEY_BRIGHTNESSDOWN, as appropriate. This will eliminate some silly errors in the acpid output.
Change events/asus-brightness-up and -down to make the hotkey line more specific: event=hotkey ATKD 00000022 and 21, respectively.
Remove asus-volume-up from events entirely, since it's entirely wrong.
Add if-asus-eee.sh to /etc/acpi containing the single line #!/bin/true. This will make the EEE-specific scripts shipped with Jaunty work. (Why that script is missing entirely is a very good question.)
Then add wifi-radio-toggle to events:
event=hotkey ATKD 00000010
action=/etc/acpi/wifi-radio-toggle.sh
This will run /etc/acpi/wifi-radio-toggle.sh when you hit FN-F2. Add that script:
!/bin/bash
STATE=`cat /sys/class/rfkill/rfkill0/state`
if [ ${STATE}x == 1x ]; then
echo "Turning off the WiFi radio..."
/etc/acpi/wifi-radio-off.sh
else
echo "Turning on the WiFi radio..."
/etc/acpi/wifi-radio-on.sh
fi
Note that if Something Mysterious happens, this script defaults to turning the wireless on, on the theory that you'll want to be able to go online to figure out why Something Mysterious was happening.
Naturally, you'll need /etc/acpi/wifi-radio-on.sh and wifi-radio-off.sh scripts, for which, see (2), above.
Next time I get a chance to hack on this I think I'll look at the other special keys. The 'LCD off' button is recognized, but may only kick in the screen-saver. It also resets the screen brightness to full for some reason. I really want to change the latter; the latter may actually be the right thing to do, in terms of letting user preferences determine what to do. The toggle resolutions button and function key don't appear to do anything, although there should be an command-line X utility for invoking resolution changes. (1024x768 scrolling mode should be supported by X's native ability for the screen and viewport sizes to be different.)
I don't have any plans for the two "user-defined" keys. I'd like to get FN+F1 (sleep) working, though, and FN+F4 & F7 [resolution and LCD off], for which I'll just use the solutions from the paragraph above. FN+F9 I'll probably also ignore, mostly because I don't care about the system monitor. I'd also like to get FN+F3 [toggle touchpad] working. I haven't had trouble recently, but I can totally see myself accidentally whacking the touchpad frequently, especially when using an external mouse. I have /no/ idea how to manage this trick, though...
Been doing some hacking away at Ubuntu 9.04 ("Jaunty")'s Netbook Remix. With the initial installation, my wireless didn't work; luckily, the wired ethernet did, and I was able to update (using aptitude, because apt-get was confused by the switch from the generic linux kernel packages to the specifically-versioned ones) and get the wireless working. nm-applet is surprisingly nonbroken these days, and keeps the static IP for my home wireless information stashed away completely distinctly from the configuration for 'whichever wireless AP you can find', which means I can just login (I'm not sure if nm-applet has to be running or if NetworkManager proper isn't keeping up) and have wireless connectivity at home or wherever without any futzing. (This is a big improvement over the NetworkManager/interface for the OLPC, for which I was doing command-line tweaks and rebooting. It's also an improvement over the Windows side of things, which insists on timing out on DHCP before "falling back" to the static IP information for home WAP. I'm worried it'll "fall back" to my home WAP's static IP if it can't a DHCP server on some other WAP...) The sound works, although the OSS mixer emulator doesn't seem to work. (This is an issue because I prefer to use WindowMaker, and I think all of its Dock mixers are OSS.)
Anyway, I got the wireless toggling working. The key thing to realize is that all the documentation you'll find online is wrong. :) For my 1000HE and installation of UNR 9.04:
1) In /boot/grub/menu.lst, add pciehp.pciehp_force=1 pciehp.pciehp_poll_mode=1 to the end of the first kernel. This will permit the wireless driver to find the card after you power-cycle it.
2) The following two scripts do things in the right order.
#!/bin/bash
# Turn the WiFi radio on.
echo 1 > /sys/class/rfkill/rfkill0/state
sleep 1
modprobe rt2860sta
#!/bin/bash
# Turn the WiFi radio off.
ifconfig ra0 down
rmmod rt2860sta
sleep 1
echo 0 > /sys/class/rfkill/rfkill0/state
Which rfkill control to use seems to be a stable mapping. (Where 'rkfill1' is the BlueTooth radio.) The scripts are deliberately asymmetric with respect to ifconfig; I don't know why (since I stole the ordering from eeepc-acpi-utilities, which, depending on the phase of the moon, break either the sound or the wifi), but they seem to work. My guess is that turning off the interface is a little rude than removing the module. (It's also entirely possible that a live network interface would prevent the module from being removed.)
It turns out that acpid actually scans /etc/acpi/events for matching events (keystroke-equivalents, usually), so you can readily set up your own mappings. If you kill acpid (sudo /etc/init.d/acpid stop) and then run sudo acpid --debug, you can easily see which keys acpid is seeing when you press them. I used that to make the following changes in /etc/acpi:
Change /etc/acpi/asus-brn-up and asus-brn-up to
#!/bin/sh
test -f /usr/share/acpi-support/key-constants || exit 0
. /usr/share/acpi-support/key-constants
acpi_fakekey $KEY_BRIGHTNESSUP
with the last line ending in $KEY_BRIGHTNESSDOWN, as appropriate. This will eliminate some silly errors in the acpid output.
Change events/asus-brightness-up and -down to make the hotkey line more specific: event=hotkey ATKD 00000022 and 21, respectively.
Remove asus-volume-up from events entirely, since it's entirely wrong.
Add if-asus-eee.sh to /etc/acpi containing the single line #!/bin/true. This will make the EEE-specific scripts shipped with Jaunty work. (Why that script is missing entirely is a very good question.)
Then add wifi-radio-toggle to events:
event=hotkey ATKD 00000010
action=/etc/acpi/wifi-radio-toggle.sh
This will run /etc/acpi/wifi-radio-toggle.sh when you hit FN-F2. Add that script:
!/bin/bash
STATE=`cat /sys/class/rfkill/rfkill0/state`
if [ ${STATE}x == 1x ]; then
echo "Turning off the WiFi radio..."
/etc/acpi/wifi-radio-off.sh
else
echo "Turning on the WiFi radio..."
/etc/acpi/wifi-radio-on.sh
fi
Note that if Something Mysterious happens, this script defaults to turning the wireless on, on the theory that you'll want to be able to go online to figure out why Something Mysterious was happening.
Naturally, you'll need /etc/acpi/wifi-radio-on.sh and wifi-radio-off.sh scripts, for which, see (2), above.
Next time I get a chance to hack on this I think I'll look at the other special keys. The 'LCD off' button is recognized, but may only kick in the screen-saver. It also resets the screen brightness to full for some reason. I really want to change the latter; the latter may actually be the right thing to do, in terms of letting user preferences determine what to do. The toggle resolutions button and function key don't appear to do anything, although there should be an command-line X utility for invoking resolution changes. (1024x768 scrolling mode should be supported by X's native ability for the screen and viewport sizes to be different.)
I don't have any plans for the two "user-defined" keys. I'd like to get FN+F1 (sleep) working, though, and FN+F4 & F7 [resolution and LCD off], for which I'll just use the solutions from the paragraph above. FN+F9 I'll probably also ignore, mostly because I don't care about the system monitor. I'd also like to get FN+F3 [toggle touchpad] working. I haven't had trouble recently, but I can totally see myself accidentally whacking the touchpad frequently, especially when using an external mouse. I have /no/ idea how to manage this trick, though...