Ubuntu 9.04 on the Toshiba Satellite L305

Previously I had written about installing Ubuntu 8.10 on the Toshiba Satellite L305. It was not without its problems, the hardware on Toshiba systems can be pretty picky. The omnibook module got the fan and brightness keys working, but on some systems, this also caused the laptop to turn itself on three to fifteen minutes after being shut down. The good news for those who had this problem is that in 9.04, the fan problem is easily fixable without the module, and with a few workarounds, the brightness keys work too. Furthermore, wireless now works out of the box with the ath5k module, so madwifi or ndiswrapper are no longer necessary.

If you are already running the omnibook module without this problem, I recommend using that instead, as it is a simpler fix.

Step 1: Install and get the fan going

Download and install Ubuntu 9.04. In my experience, the DVD drive in the L305 can be a little picky, so I recommend either installing from a usb stick or burning the Ubuntu CD at a slower speed. The installation should go smoothly. When it boots to your new Ubuntu desktop, you first need to get the fan going.

This is a pretty easy fix, all you need to do is modify your grub file. Open up a terminal and type:

sudo gedit /boot/grub/menu.lst

*note: You can use nano, vi, kate, or whatever your preferred text editor is.

Add 'acpi_osi="Linux"' to your kernel's boot parameters. This is an example of my menu.lst file, with the part you need to add in bold (the rest may differ slightly in your file):

title Ubuntu 9.04, kernel 2.6.28-11-generic
uuid a91f7379-e93b-490c-b541-0681173bccc2
kernel /boot/vmlinuz-2.6.28-11-generic root=UUID=a91f.. ro quiet splash acpi_osi="Linux"
initrd /boot/initrd.img-2.6.28-11-generic
quiet

Reboot and your fan should work fine. In my experience, it turns on at about 50 degrees and turns back off at about 35. Your brightness keys might be usable now, too. In my experience, though, these keys stop working after a few reboots. (If your keys continue to work, you can skip the brightness keys workaround section).

Optional: monitor your temperatures with lm-sensors
I wanted to make sure that the fan was working appropriately, so I wanted to monitor the computer's temperature. This is easy to do by installing the lm-sensors package. After you set up the sensors, you can either run the sensors package to display temperatures, or install the sensors-applet package to monitor them from the desktop:

sudo apt-get install lm-sensors sensors-applet
sudo sensors-detect

sensors-detect will set up the sensors. It will ask a lot of questions, the defaults should all be fine, though when asked if I want to add the modules to /etc/modules, I say yes. either reboot or manually add the modules it specifies manually. Add the sensors applet to the panel and you should be able to monitor your temperatures.

Step 2: Get the brightness keys working
For some reason, after a couple of reboots, the function keys no longer work for me. It seems the function key (fn) doesn't get input. I've developed a workaround to make the super (Windows) key to work with F6 and F7 to change brightness levels.

First you need to modify the keyboard with xmodmap to allow the use of the super key, because by default it is set to a different use. Though it is supposedly changeable through Gnome, I have had no luck. It is actually quite easy to do manually though.

First open a console and run xev. Hit the windows key and look for the keycode output. On my computer, it is 147, though may be different (there are a few different models of L305s). Close out of xev and make (or modify) ~/.Xmodmap (note the dot and the capital X). Add the following lines to .Xmodmap:

keycode 147 = Super_L
add mod4 = Super_L

Save and close the file, then run xmodmap. The super key should now be mapped to "Super_L" (you can test this again in xev, if you like)

Next you need to bind super+F6 and super+F7 to the brightness keys. This is doable with xbindkeys, which is installable in the console, and you may also need the keytouch daemon: (sudo apt-get install xbindkeys keytouch). Xbindkeys will be mapped to run acpi keys with "acpi_fakekey", which should already be installed on your system. The keytouch daemon will install apci-related things that make acpi_fakekey work (I'm not exactly sure how, but in my experience, without the keytouch daemon, acpi_fakekey doesn't work)

You are also going to need to install the lineakd package to find out what the event keys are for your brightness keys. Lineakd comes with a program called evtest. Run it (as root) on the different events in /dev/input/ until you find the one with brightness event codes. Mine is in /dev/input/event5, though it may be different for you:

sudo apt-get install lineakd
sudo evtest /dev/input/event5

It lists for me that brightness down is 224 and brightness up is 225.

Next you need to modify the xbindkeys config file. This is easiest by installing the xbindkeys-config package, and run that. Here you can add various commands for different combinations of keypresses. Click “add.” Name the command whatever you like. Click on “get key” and press your key combination. For the action type in “acpi_fakekey [keycode]”, where [keycode] is the event code you found with evtest. For example, for my brightness down key I put acpi_fakekey 224. You can also use this for other commands, too.

Save the file and close xbindkeys-config. Here, I like to move the config file from its default location (~/.xbindkeysrc) to its own folder in /etc, because the commands should be system wide, and also for security (the commands it will be running will be running as root). I copied it to /etc/xbindkeys/xbindkeysrc

Now it's time to test it. run xbindkeys as root with "sudo xbindkeys -f [location of xbindkeysrc file]" . Press super+F6 and super+F7 to make sure they adjust the brightness as they should. If everything is set up right, your brightness should be changing now!

Step 3: Get xbindkeys to run at boot:
As long as the keys are working, the only thing left to do is to make xbindkeys run on boot. The following is the only way I've been able to find to get that to work (init scripts make it run too early and it segfaults). Many thanks to Ubuntu Forums user BslBryan for this tip!

First, modify the sudoers file with the command "sudo visudo" Add the following to the end of the file:

[your username(s)] ALL= NOPASSWD: /usr/bin/xbindkeys

This makes xbindkeys able to be run as root without a password. It's important for the next step. Next go to System -> Preferences -> Startup Applications. Click on add. Name it xbindkeys. For the command, type "sudo /usr/bin/xbindkeys" (without the quotes). Sudo won't ask for a password now because we edited the sudoers file earlier with visudo. Type a description if you like and click add, then close out of startup applications.

Now reboot. If all went well, when you reboot super+F6 and super+F7 should adjust the brightness. Along with the easy fix for the fan, this makes Ubuntu 9.04 much more usable on newer Toshiba laptops.

How to use LIRC with Amarok 2, Exaile, and other media players in Ubuntu

It has been a while since I updated. School and life in general have kept me busy, and I haven't had many adventures in Linux, but today I had to grapple with a new problem.

Amarok 2 was released last December and after I first tried the beta, I really didn't like it. Amarok 1.4 was my music player of choice, you see, but the times, they are a changin'. In the upcoming release of Ubuntu (Jaunty Jackelope, 9.04) Amarok is due to be replaced by version 2. I decided to try out Amarok 2 again, figuring I will either have to get used to it, or find myself a new player.

Truth is, I still hate Amarok 2. And while I could go into details on that, it is not the reason I am here. When I was first trying to learn to love Amarok 2, I spent a while trying to fix one of my main annoyances with it: lack of support with LIRC (Linux Infrared Remote Control.) In 1.4, the DCOP server made things extremely easy, but it no longer exists in Amarok 2, and so you have to get creative. Edit: *As pointed out in the comments for this post, DCOP was actually replaced with DBus, which I managed to miss somehow. I admittedly don't know much about DBus myself, but if you are interested in getting LIRC working with Amarok 2, you will save yourself some effort looking into DBus. However, this guide still applies to Exaile and any other media players that don't specifically offer remote control support. Thanks to nhnFreespirit for pointing this out!*

As I found out, this guide will also work for other music players. In addition to an already set up LIRC daemon and remote control, you will need an audio player with either global hotkey support (like Amarok 2) or a media player that can take advantage of the keyboard shortcuts (the default way to use media buttons on a keyboard) in Gnome. You might also need a keyboard with media buttons, but I haven't tried it without them, so it may work (if it does, you should let me know!) These instructions are taken from three or four other resources that, in my exhaustive search, I lost and so can't give proper credit, but thanks to those who paved the way.

Step 1: Global Hotkeys
The first thing you need to do is set your global hotkeys to your media buttons. If you are using Amarok 2, this needs to be done within Amarok (go to the configure shortcuts dialogue, and set your global hotkeys for play/pause, stop, next track, and previous track to the corresponding media buttons on your keyboard. If you are using a Gnome/GTK+ music player, you should be able to set these under Preferences -> Keyboard Shortcuts. In either case, you should now be able to control the music with these media buttons.

Step 2: Set LIRC to use acpi scripts
There are scripts in /etc/acpi/ that will actually control these multimedia button functions, and if you tell LIRC to use them, you can get your remote to tell the computer that you actually hit that button on the keyboard. The associated scripts are are called playbtn.sh, stopbtn.sh, nextbtn.sh, and prevbtn.sh. You can use irexec to run these scripts by setting them up in the ~/.lircrc file. For example, I have included the play button and stop button from my .lircrc file:

begin
prog = irexec
remote = AtiRW
button = play
config = /etc/acpi/playbtn.sh
end

begin
prog = irexec
remote = AtiRW
button = stop
config = /etc/acpi/stopbtn.sh
end

*Note, your "remote =" and "button=" will vary depending on how you set up your LIRC daemon. In my example, I named my remote "AtiRW", my play button "play" and my stop button "stop". These values come from your lircd.conf file when you set it up.

Set all of the buttons you want. You can even set up the vol+/vol-/mute buttons on your keyboard if you have them to change the master volume, though I prefer to use aumix or amixer to do that because there is no OSD.

When you are done setting up your keys in ~/.lircrc, save the file and close it. Then run irexec as root in the terminal with "sudo irexec" (It should have been installed with LIRC, but if it hasn't, you can install it with apt-get first.) If you have set up everything correctly, at this point you can press the buttons on your remote and it should cause the music player to function accordingly. If it doesn't work, make sure A) You set up LIRC correctly (I didn't cover that here), B) LIRC is currently running, C)You ran irexec AS ROOT (you will get an error otherwise), and D) Your media buttons on your keyboard work.

Step 3: Get irexec to run at boot
For me, irexec (the program that tells other programs/scripts to run based on LIRC input) was automatically told to run at start up with LIRC. However, even if that is the case for you too, to run these scripts irexec has to be running as root so you will have to do this next step either way. For whatever reason, and the sources I found on the internet seem to confirm it, the usual methods for starting irexec always seem to result in them being run as a normal user. We are going to have to get around that.

It would be a good time to note that, for good reason, running programs as root should be done with the utmost caution, and the only reason we are running irexec as root is because running the acpi scripts have to be run as root. (I even tried copying them to my home directory and changing the permissions/ownership with no luck.) Anybody with an alternative method that does not require irexec to be run as root should leave a comment on how to do it and I will update accordingly.

The only way I managed to get irexec to run as root was found here thanks to Ubuntu forums user Kipee. They suggest adding it to crontab. Edit crontab with:

sudo crontab -e

You may be asked which editor to use, if so just select whichever one you are most comfortable with. Add a new line and insert the following, replacing USER with your username:

@reboot sleep 30 && export DISPLAY=:0 &&/usr/bin/irexec -d /home/USER/.lircrc

"@reboot" tells it to run when the machine is booted. "sleep 30" causes irexec to wait 30 seconds before starting, and is only to make sure that the LIRC daemon is running before trying to run irexec. (Note: in Kipee's post, they use 120, but two whole minutes seems longer than necessary in my experience). Close out of crontab (ctrl+x if you are editing with nano) and make sure to save it. Now reboot. When the machine reboots, irexec should now start running (remember, after 30 seconds), and when you open up your favorite media player, it should respond to remote control input.

Other Considerations
These directions assume you have multimedia buttons on your keyboard, and I am not entirely sure how one could achieve the same effect without those multimedia buttons. (If you try running the acpi scripts without assigning them to a key, they don't work!) If you are using a player with configurable shortcut keys (like Amarok 2), I would imagine it would be possible, though I haven't tried it, to use irxevent to fake keypresses in that program (for example, set ctrl+p to play in Amarok, set the play button on your remote to sent "ctrl+p" to Amarok.) Edit: *as mentioned previously, for Amarok 2 use DBus instead.* This would also bypass the need to run irexec as root (or in fact, at all.) You Alternatively, the scripts that run the multimedia keys are tied to key numbers given in /usr/share/acpi-support/key-constraints, and it *might* be possible to use those even without multimedia keys, though how you would do that is beyond me, and if you attempt it you do so at your own risk. Any other solutions to this problem? Feel free to leave some comments.

And in case you were wondering, I switched to Exaile, and now that I've bypassed the hurdle of being able to use my remote, I am loving it.

Steps to a successful 64-bit Ubuntu

Completely on a whim I decided to try Arch Linux on my laptop, which had some hardware issues, and then later on my desktop. While I liked it, it was way too much work for me, given the fact that I use Linux almost exclusively and need something functional. When it came time to reinstall with an easier distro, I decided to go back to Ubuntu if only because I spent a decent amount of time trying to tweak Debian that is unneeded in Ubuntu. However, I decided to go with the 64-bit version, which comes with its own set of problems that can be overcome with a little knowhow.

Previously, I wrote on how to set up a chroot environment to run 32-bit programs in their own 32-bit environment, all within the 64-bit operating system. (I wrote it for Debian Lenny, but the same process can be used for Ubuntu if tweaked slightly.) It works, but it is not without limitations. The biggest of which was running a 32-bit web browser caused problems with other web browsers arguing for the title of "default browser," and being unable to run downloaded files from within the browser. I decided this time I was going to try to do it all without using a chroot.

Web Browsing:
Adobe Flash has always been tricky to get working on a 64-bit browser. This will soon change, as Adobe currently has an alpha version of flash, but I have tried it and it is (as one would expect for alpha software) quite buggy and unstable. The other common alternative is to run the nspluginwrapper package to use a 32-bit flash in a 64-bit browser, but this can also be quite buggy for some. My solution is simply to run a 32-bit browser. I don't know how well all 32-bit browsers run, but I would recommend Swiftfox, which is basically an optimized Firefox, and I recommend it because it comes in a very easy-to-install .deb file. The one thing you have to do is figure out what sort of processor your computer uses, because different packages are optimized for different processors. After you find your processor, you can download the appropriate version of swiftfox here. (My computer uses the Prescott version, so I am going to use it in the examples) Then install it in the terminal:

sudo dpkg -i swiftfox_3.0.4pre-1_prescott.deb

Even though it is a 32-bit browser, it *should* install just fine. Open it up and make sure it works. One thing to watch out for is that on Debian, it did not find the printer I had installed, though I have never had problems with it in Ubuntu. If everything works in Swiftfox, you are ready to install Flash. Download the latest version from Adobe. Download the .tar.gz file (NOT the .deb file), navigate to the downloaded file and extract the contents. Copy libflashplayer.so to the plugins directory in your home directory:

tar -zxvf install_flash_player_10_linux.tar.gz
cd install_flash_player_10_linux
cp libflashplayer.so ~/.mozilla/plugins/

When you start up Swiftfox again, you should have working Flash support.

Adobe AIR:
I like the Adobe AIR runtime to use TweetDeck, but it is still not supported in 64 bit. The latest version will run on 64-bit versions with a few tweaks, and Adobe is kind enough to supply the information on their website. Rather than rehash what they have, I would recommend just checking out their website. If you follow their guide exactly, Adoebe AIR should run beautifully.

The getlibs Package:
For many other programs that have no 64-bit version, installing the 32-bit libraries will often be enough to get them up and running. The easiest way I have found to do this is with a package called getlibs, which can be found at http://www.boundlesssupremacy.com/Cappy/getlibs/getlibs-all.deb. This program will assess 32-bit packages/binaries and figure out which 32-bit libraries it needs to run successfully. For this example, I am going to use the Amazon.com mp3 downloader. After downloading it, if you try to install it with dpkg, it will fail, claiming that you are attempting to install something for the wrong architecture. This is an easy enough fix using the --force-architecture option when installing:

sudo dpkg -i --force-architecture amazonmp3.deb

The package will install but will still give you errors if you try to run it. To fix this, install getlibs if you have not already, and then run it on the binary file (not the .deb file) and it will, after a few moments, download and install the required libraries:

sudo dpkg -i getlibs-all.deb
sudo getlibs /usr/bin/amazonmp3

My one complaint with getlibs is that it does not provide any detailed output, so it may seem like it is not doing anything, but be patient. Once it completes, try running your program again and it should run. If the installer for a program is in .bin format, try running getlibs on the .bin file first because that might work as well (like in the directions for installing Adobe AIR), but so far it doesn't seem to do anything for .deb files for me. If a program complains of a missing library file, getlibs can also be used to download that specific library with the -l (or -64l for 64 bit libraries) option. And if downloading the libraries doesn't seem to work, try updating your library links with "sudo ldconfig".