HowTo test newest radeon/radeonhd/mesa from a live CD

[tormod]

I have set up a Ubuntu package repository for development versions of Xorg components (see https://wiki.ubuntu.com/XorgOnTheEdge). This can be used from a Ubuntu live CD, to safely test without modifying your normal installation.

1. Boot from a Ubuntu 9.04 Desktop CD (http://www.ubuntu.com/getubuntu/download). To save fossil trees, please use a bootable USB stick instead of burning CDs. Run "usb-creator" to install the ISO image onto your USB stick, or see for instance https://help.ubuntu.com/community/In...n/FromUSBStick for the hard way.

2. If you use wireless networking etc, get connected to internet.

3. Download the xorg-edgers-live-test script from https://wiki.ubuntu.com/XorgOnTheEdge (if you haven't already copied it to your USB stick)

4. Only for using the radeonhd driver:
Run the command

sudo apt-get install xserver-xorg-video-radeonhd

or edit the xorg-edgers-live-test script and uncomment the corresponding line in the script. If radeonhd is installed, it will be picked instead of radeon.

3. Switch to a virtual console with Ctrl-Alt-F1

4. Run

sudo sh /cdrom/xorg-edgers-live-test

if you copied it to your USB stick, or if you just downloaded it:

sudo sh ~/Desktop/xorg-edgers-live-test

5. Sit back and breath calmly, and watch while your computer loads and fires up fresh Xorg goodies.

Note that the package repository is updated more or less regularly, and things might break. That's the nature of development versions.

EDIT: updated to 9.04

[tormod]

Just a little trick to save download time if you use the live "CD" several times (I suppose of course you're using a USB stick). After the script has downloaded the packages, they are kept in /var/cache/apt/archives on the live virtual file system. If you run the script again with the "savedebs" command, it will save the packages to your USB stick. The script will then find the packages there the next time and the package manager won't need to download them again.

sudo sh /cdrom/xorg-edgers-live-test savedebs

Note: The script will use a subdirectory called "archives" in the same directory as itself, so the above supposes you have copied the xorg-edgers-live-test script to the USB stick.

[oblidor]

Works very well! But how can I install it in a real system? The script aborts due to that it is not a live system.

[Kano]

The live check must be a bad joke There are much better ways to check for a casper live cd.

[ -d /cdrom/casper -a -d /rofs ] && echo live mode found

But you see that this script has a similar hack that i needed to add to my fglrx/nvidia scripts to make it work with ubuntu 8.04 live cds.

killall gdm

of course only killing gdm means that you have to use ubuntu, as you need something else for kubuntu and also something else like when you want to use the kde4 variant of kubuntu (i added that a few days ago to my scripts).

For the tty check: thats maybe a bit too restrictive, i check for DISPLAY, as when you want it extra tricky you can use

sudo -i
DISPLAY= nohup sh install-fglrx-debian.sh

for example. nohup allows you to run the script in the background but even inside X (for Kanotix Live mode i even embedded this inside the script - so you dont need that hack in live mode).

[oblidor]

sudo -i
DISPLAY= nohup sh install-fglrx-debian.sh

for example. nohup allows you to run the script in the background but even inside X (for Kanotix Live mode i even embedded this inside the script - so you dont need that hack in live mode).

I don't think I want to mess anymore with fglrx. I'll stick to the open source drivers which seems to be far better.

I hacked the live cd script for the open source ati so that it doesn't check for live CD. and tried to install the drivers with it. I had previously tried the other recipe on the wiki and failed. with the script it was same failed result. But then I thought that I have been messing so much now with the system and installing fglrx etc.. so lets make a complete reinstall. I have only used ubuntu for a couple of days so I hadn't have time to install all the software I wanted anyways.

After the reinstall I again hacked the script and ran it. Now it worked! I get much better video playback. Little CPU usage. I still gets some lags from time to time, but not sure if that had to do with background programs. Will check it further. The video playback is much smoother now, actully too smooth so a DVD look a bit like old VHS quality, but I'll check if this is a vlc problem.

Anyway the open source drivers seems to really get things working! And I guess by fall it will be much better and possibly going into the ubuntu.

Now the big question is: Can one expect the same from the 4850 or similar? Because if one can relay on working open source drivers it is 10 times better than closed source ati or nvidia drivers if you get into trouble... Besides the mobo (type: P45 or X38) I'm considering has Crossfire possibility if I would want to improve the system with another ati card.

[Kano]

Of course that was only an example - you do not need to use my script. But you can use the same check that I use:

Instead of:

TTY=`tty`
if [ "${TTY%?}" != "/dev/tty" ]; then

use:

if [ "$DISPLAY" ]; then

or the same is:

if [ -n "$DISPLAY" ]; then

[tormod]

Kano, thanks for the suggestions. At this point I just want to make sure people are running it on an unmodified Ubuntu CD, so the check will do (it's not a joke, it's heuristics ). I could add your casper check though. But even persistant live USB sticks could get complicated, if I just checked for a live "CD".

Since I want to have well-checked platform to base everything off, I "support" only the Ubuntu 8.04 live CD at the moment. I only have time for minimal testing myself, and I don't want people to waste their and my time with debugging "funny" issues because they are running some other setup. They can always edit the script themselves. Basically the message is: If you don't know how to edit a script file, stick to my setup, which I have tested myself

OTOH, if you would like to see this supported on for instance a Debian snapshot live CD, we could do this together, but someone else would have to test that platform. I guess we don't really need several live CD options though. I don't want to make a new distribution out of this either.

Similar for the tty testing. I really want people to switch console themselves. If they don't know how to do that, they should not play with X drivers, seriously. Letting the script run nohup it would be difficult for people to see informal/error messages as well. If the script breaks half way, it's good they have X left to switch back to browsers etc.

So minimal flexibility is part of the design. Keep it simple (&) stupid!

[tormod]

As you can see from my recent hiatus, it's summertime and occasional (off-line) vacations around here. So I don't intend to update the packages very often (unless it rains). It's set up to be a group effort though, anyone in the xorg-edgers launchpad group can upload updates. For the same reason, membership is moderated.

Currently, Debian experimental is catching up with the git versions (and us ) at least until mesa 7.1 and xserver 1.5. This (and that upstream seems to stabilize a bit) means that the xorg-edgers job will be easier for a while. However we might jump to xserver trunk later. After all, we want to stay on the edge.

The live CD test will probably jump to Ubuntu 8.10 alpha CDs when they are available, so that we can be more up to date with kernels and system libraries. I will keep building Hardy packages though as long as it stays uncomplicated, since many people would like to install them on their stable Ubuntu 8.04 setup (as I do myself).

[tormod]

The latest packages from today introduce some input hot-plugging changes. On my system, mouse and keyboard doesn't work unless I add this to xorg.conf:

Section "ServerFlags"
        Option "AllowEmptyInput" "false"
EndSection

[tormod]

I gave the packages an update today. Now we're slightly ahead of Ubuntu Intrepid again Most distributions seem to be unusually up to date nowadays. (Well for Debian, think "experimental".)

The AllowEmptyInput option still needs to be disabled on my test setup. I also updated the evdev input driver but that didn't help. For more information on evdev see http://who-t.blogspot.com/2008/07/in...-nutshell.html