tensixtyone

My grand idea of experimenting with various distributions for the EeePC went wrong, by quite a bit as well. As mentioned in the last post I decided to have a play around with some of the distributions specifically built for the Asus EeePC 701, I was wondering if something out there can beat Debian on this little work horse.

Oh boy was I wrong.

First I attempted to install Zeee (Zenwalk for the EeePC), the installation “media” came as a compressed disk image, nothing that unusual as most of the distros come in their own little installation media package. It turns out that this image is a raw dump of a file system, so I had to create the installation media on a USB stick with the various handy tools, mke2fs, grub, you get the idea. After about 45 minutes of fiddling I called it a day, for some reason the GRUB installation wasn’t detecting the ext2 partition on the USB stick, and couldn’t find the menu.lst file. While this is probably a simple issue it’s a bit more than I could be arsed with, the Zeee guys are doing well but the installation method need a little work, maybe a prepackaged ext2 dump.

After the kerfuffle with Zeee I moved onto the latest Foresight Linux Mobile Edition, I’ve heard Dan & Fab mention Foresight on the Linux Outlaws podcast and I have downloaded a live CD previously, so I decided to get the image and have a go. This installation went a lot easier, the image was a precompiled usb installation so no hassle there, the installation took time but I put t hat down to the quality of the USB stick I was using. After about 30 minutes I had a working Foresight Linux install, and everything seemed to work out of the box, including the WIFI (which is the usual sticking point for most distros).

Foresight Mobile uses the clutter based launcher you can also find in the Ubuntu Netbook Remix, the mainstream applications are pre-installed and are usable. Within a few minutes I hit my all time pet hate, touchpad clicking, ever since i’ve owned a laptop I’ve never been able to use touchpad click to any degree of success and I don’t see any reason why it should be enabled by default. In previous distribution I know the way to fix this issue is to simply changing the settings in gsynaptics or modify the Xorg config, as I was trying to operate from a user perspective I went the simple route of using gsynaptics. It wasn’t installed. I went digging around in the package manager (conary) and didn’t find a related package. After about ten minutes searching I found the “synaptics” package, which proved useless as I had no idea of what it does.

Three hours in and my experiment with Foresight was over, people may complain that it’s a simple issue but having the option enabled by default and then hiding the configuration in a non standard package doesn’t help matters. I have to give Foresight kudos for being one of the first distributions to have a full “netbook” version, but it still needs a little refinement.

So, now I’m back on Debian, tried and tested. This time I installed using the updated Lenny installation media for the EeePC and it was a breeze, and since I’ve done this “fresh install” a lot more of the features work consistently. In the process of configuring my machine again I’ve noticed that the older guide for the E160G using Network Manager is a little wrong, so I’ll have to update that sometime. For now I’ll be sticking on ol’ faithful. Maybe when the “next big distro” gets released I’ll give it a try.

I’ve been using Debian on my EeePC 701 since I got it, I think the original Xandros lasted a whole two hours or so. Over the last few days i’ve been bugged by 2.6.26 issues and various XServer issues, time for a change.

Over the next few weeks it’s my plan to experiment with a few EeePC tailored distributions, much in the same way Dan did. My first distro of choice is Zeee, which is a customised version of Zenwalk. I’ve heard good things about Zenwalk, so now is my time to experience it.

So, I’ll post a follow-up tomorrow.

So, in my last post I described how it was using the E160G with Debian. All in all it’s very good and i’ve not experienced any major issues, bar a few minor apt-get and NetworkManager issues. So, heres a quick rundown of how to get it on your machine.

So first, you need to get the hardware to work correctly under Debian. Plug in your E160G and check dmesg to see if the device recognises correctly. If you see ttyUSB0/ttyUSB1 appear you can skip this step.

First, you need to download USB_Modeswitch:

# wget http://www.draisberghof.de/usb_modeswitch/usb_modeswitch-0.9.4.tar.bz2
# tar jxvf usb_modeswitch-0.9.4.tar.bz2
# cd usb_modeswitch-0.9.4/
# ./compile.sh

Now you have the usb_modeswitch program, as this will be executed by udev it needs to be in a sensible location, personally i’d copy it to /usr/local/sbin/

# cp usb_modeswitch /usr/local/sbin/

Also, you need to grab the latest config file from the usb_modeswitch website and put it into /etc

# wget http://www.draisberghof.de/usb_modeswitch/usb_modeswitch.conf
# sudo mv usb_modeswitch.conf /etc/

Now, by default the config file comes with the section commented out, so edit the file and uncomment the section for the E220 (which is essentially the same device).

# sudo $EDITOR /etc/usb_modeswitch.conf

One last step, you need to add a small configuration file to udev to detect the E160G and run usb_modeswitch, put this file in you /etc/udev/rules.d/ folder:

SUBSYSTEM=="usb", SYSFS{idProduct}=="1003", SYSFS{idVendor}=="12d1",
  RUN+="/usr/local/sbin/usb_modeswitch"

Restart udev, and plug in your E160G…

sudo /etc/init.d/udev restart

and you should see something similar to:

[   16.085904] usb 5-3: GSM modem (1-port) converter now attached to ttyUSB0
[   16.086033] usb 5-3: GSM modem (1-port) converter now attached to ttyUSB1

So, the device is detected and you have your USB ports, first a quick overview. The E160G shows two serial ports, one is a data port, the other is for control signals. NetworkManager only makes use of one of these ports but the Vodafone Connection Manager uses both. Now you have a choice, install Network Manager 0.7 to gain native GPRS/UMTS data support or use another package. I went for Network Manager, while it’s still in beta and i’ve had a few run-ins in the past with it I decided to give it a go.

So, it was a simple case of adding the 0.7 repositories to /etc/apt/sources.list, updating, then installing the needed packages.

# echo "deb http://debs.michaelbiebl.de/ unstable main" >> /etc/apt/sources.list
# apt-get update
# apt-get -t unstable install network-manager

You might need to remove any old Network Manager packages before you do this, as network-manager-openvpn collides with the new package.

Hopefully thats give you the overview you needed, and you should be up and running!

The eee-acpi module, hacked by Asus from the asus-laptop module, currently manages the kill switches for the various extra hardware (wifi, cardreader, webcam) and also handles the extra Fn keys via ACPI events.

While hotkeys via ACPI are well supported by acpid and its ilk it is no longer the best way to handle these types of keys. Generally, the drivers for the mainstream laptops (ibm/lenovo, hp) have moved over to the input framework to communicate these key presses, usually displaying as an extra input device under /dev/input. These input devices can be handled by HAL and notifications of key presses send over the dbus allowing for desktop environments such as GNOME to handle these events without any strange hackery and fakekeys calls.

Thanks to the previous work of the asus-laptop developers there’s a patch that exists to disable the existing ACPI events and provide a input device for the extra keys, I’ve managed to hack together a version of the eeepc-acpi module using the Debian 1.01 source to export the “Asus Extra Buttons” input device.

After you have the inputs available, it’s a simple matter of producing a FDI for HAL to identify the device and map the scan codes to the actual keys. After the initial FDI was created I could use the volume keys without any extra software and also map the two application buttons (marked as VGA switch, and AP button) in GNOME to call scripts. The wifi key (Fn+F2) presented more of a problem, while it was mapped to “wifi” HAL didn’t know how to actually switch off the Atheros card. The killswitch for the card would need to be implemented as a program that listens to dbus, something a little outside my skill set.

The other buttons on the keyboard (sleep, brightness) are pure ACPI calls. This presents a problem that the keys produce events via the input layer and the ACPI layer at the same time, so for example you hit the brightness down button and HAL will pickup the notification and display the brightness OSD, but it quickly goes out of sync as what HAL sees and what the ACPI are doing are completely separate. Again, this is outside my skill set but I’d probably approach it by filtering out the keys in the kernel and let the ACPI events do their work.

The guys over at Fedora have a similar idea of moving over to an input based module, but for the moment no source has been produced. Due to the numerous little issues I’ve had I’ve decided to put this little project on the back-burner until I see what the Fedora people have produced, after all they’ll have people that are more experienced in this type of thing, whereas I am not.

I’ll get round to posting the source deb for the modified eee-acpi tonight or tomorrow.

After initally setting up my EeePC to run Debian Lenny I quickly encountered a issue were the madwifi drivers wouldn’t resume correctly. The card would be unable to operate as it has lost sync with the kernel drivers, removing and reloading the related modules solved the issue.

Some people on the EeeUser forums ripped out the existing script from the default Xandros install, a simple acpi script that jumped through some hoops to disable the modules and clear everything down. The script worked as part of the existing acpi-support package and worked when using the acpi suspend options, now i’ve got GNOME and HAL installed it turns out these are no longer used, therefore still causing the issue.

After a little research it seems that the suspend support within Debian is currently in a state of flux, and a few bug tickets have been raised about the various issues. This provided my first hint of how to resolve it, a quick script in pm-utils, much like the acpi one, will fix this for good.

Simply, place this script into your /usr/lib/pm-utils/sleep.d/ folder, I’ve got it as 45eee-wifi that way if the script fails for some reason at least your video will be resumed.

#!/bin/bash

PWR=$(cat /proc/acpi/asus/wlan)

load_modules() {
   modprobe ath_pci
   modprobe wlan_wep
   modprobe wlan_tkip
   modprobe wlan_ccmp
}

unload_modules() {
   rmmod ath_pci
   rmmod wlan_scan_sta
   rmmod wlan_tkip
   rmmod wlan_wep
   rmmod wlan_ccmp
   rmmod ath_rate_sample
   rmmod wlan_acl
   rmmod wlan
   rmmod ath_hal
}

wifi_on() {

   if [ "$PWR" = "0" ]; then
      modprobe pciehp pciehp_force=1
      sleep 3
      echo 1 > /proc/acpi/asus/wlan
      sleep 2
      load_modules
      sleep 1
   fi
}

wifi_off() {
   if [ "$PWR" = "1" ]; then
      unload_modules

      echo 0 > /proc/acpi/asus/wlan
      sleep 1
      rmmod pciehp
      rmmod pci_hotplug
   fi
}

case "$1" in
        hibernate|suspend)
                wifi_off
                ;;
        thaw|resume)
                wifi_on
                ;;
        *)
                ;;
esac

The scripts in the “Arch acpi-eee” package provided the basis for this script, and it also works alot better than the existing scripts provided on eeeuser.com.