Archive

Posts Tagged ‘X.org’

Using ATI Catalyst drivers on Ubuntu 12.10 with old hardware

February 14th, 2013 No comments

As of version 12.10, Ubuntu has upgraded the version of X.org they include to the latest and unfortunately it is no longer compatible with the official ATI Catalyst drivers for some cards, specifically the HD2xxx, 3xxx and 4xxx models. The open source driver is the only officially supported alternative and, while it is fine for most uses, it doesn’t support the advanced power settings that the ATI driver does. This means that on my laptop in particular the fan runs constantly as it tries to cool down the overheating card.

So… no Ubuntu 12.10+ then?

Thankfully someone has created a PPA that successfully downgrades the version of X.org to the maximum supported version for the official ATI driver. This step is obviously quite drastic and should not be used on production systems. However from the limited time that I have been running it things seem pretty stable. The PPA (and instructions) can be found at this link: AMD Catalyst Legacy




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.
Categories: Tyler B, Ubuntu, Xorg/X11 Tags: , , ,

Gentoo (A.K.A. “Compiling!”)

October 30th, 2011 No comments

For this version of the experiment I have chosen to try my hand at installing Gentoo. Gentoo, for those who don’t know, or who weren’t following Jake’s posts during the original experiment, is a fully customizable distribution where you have to compile and install all of your applications from source code downloads. Thankfully they do offer some excellent package management tools, Portage in particular, that help automate this process.

Preamble

I suppose a bit of background is the best place to start. During the original experiment I ran Fedora which, while having a whole host of issues of its own, was more or less a straight forward experience. Since that time I’ve dabbled here and there with other distributions, Ubuntu, openSUSE, Linux Mint, among others. For this experiment I wanted a bit of a challenge. I now know the basics, and then some, about running a day-to-day desktop Linux system but I still don’t fully understand all of the inner workings that are going on under the hood. That’s where my choice of Gentoo comes in.

Getting Started

I began by following the rather excellent Gentoo Handbook which thankfully got me to the point where I was able to boot my machine, without the installation media, into a kernel that I had personally configured and compiled. To say that this was smooth sailing probably isn’t accurate, but considering what was actually involved in getting to this point, and how quickly I managed to do it, is a testament to how easy the guide actually is to follow along with.

One thing I would stress to Linux users who may want to try Gentoo and are coming from a more user friendly distribution like Ubuntu is to make sure to get a list of hardware before you start. Run lshw in your Ubuntu (or whatever) install and save the output somewhere. This will show you the list of hardware devices and more importantly the drivers required to run them correctly. I ran into a snag early on where my network card wasn’t working even though Gentoo claimed to be loading the drivers correctly. A quick modprobe later of the driver that was shown to be in use from my earlier install, tg3, and I was back and Internet enabled. Sadly even the lshw output didn’t provide a whole lot of direction when it came to picking and choosing some of the more obscure configuration options for my kernel.

The Challenge

So what do you do when you can finally turn your computer on and boot into your kernel? Well install X I suppose. Unfortunately it was this step that caused me more grief than any of the others. You see apparently you’re supposed to remember what graphics card is in your machine before you try and build a kernel that supports it…

Following along with the X Server Configuration Guide I made it all the way up until the point when I had to specify which “in-kernel firmware blobs” I wanted to compile into my kernel. After, literally, hours of compiling X and then a series of trial and error attempts I finally found a combination that seemed to work. For my own reference the only firmware blob I seem to require is

radeon/R700_rlc.bin

The Wait

I finally had a system that could start X and present me with multiple(!) graphical terminals. By this point I had sunk about ~5 hours into this project. Now it was time to try setting up a desktop environment. My two main choices were GNOME 3.x or KDE SC. I opted for KDE for two reasons:

  1. I hadn’t used KDE 4.x in a couple of releases and didn’t mind it last time I had tried it
  2. I have yet to try GNOME 3.x but since it is quite the departure from the 2.x series I figured I would go with what I know for now and maybe try GNOME 3.x later

Pulling up the Gentoo KDE guide I began my compilation of KDE SC.

emerge -av kde-meta

More than 400 packages needed to be compiled and installed. My system, a Core2Duo at 2.4Ghz and 4GB of RAM, took approximately 24 hours to finish this single process. Gentoo is certainly not a system that you can expect to have up and running in an afternoon if you’re expecting to have a fully working desktop environment.

Miscellaneous

USE Flags are ridiculous. I understand the concept for them but the fact that you have to continuously add to this list in order to compile programs you explicitly told it to install is a bit much. If you don’t know what a USE Flag is consider yourself lucky. For those thinking about installing Gentoo, don’t worry you’ll know soon enough.

Be sure to change the root password and add any user accounts after you chroot into your new installation. Otherwise you’ll end up like me and boot into a system that you can’t log into!

Next Steps

Well I’d like to finish setting up my desktop. I now have KDE installed but there seems to be some missing components that I hope won’t require a re-compilation… I’ll let you know how that turns out. I also need to sort out my wireless card and get that working. But hey at least for now I can browse the web in my new installation!




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.
Categories: Gentoo, KDE, Tyler B Tags: , , ,

Two monitors. Different resolutions. One desktop.

July 1st, 2011 6 comments

If you’ve ever tried to set up two monitors on Linux you’ll know that its a relatively painless process. The only issue that I’ve found comes when the two monitors in question do not share a common resolution between them. In testing a setup of mine I found that when I extended my desktop across the two monitors I was actually left with a ‘dead’ space above one.

Pictures make it easy to understand

As you can see in the above picture there is a space above my left monitor. The way that X does monitor spanning is to create a large ‘logical’ monitor by stacking your real monitor’s resolutions side by side. In effect this created a logical monitor of size 2640×1024 (the total width of the two monitors’ resolutions by the largest of the two’s resolution).

This dead space left me with areas above my left monitor where applications were still being shown, even though I couldn’t see them. Obviously this was unacceptable. Thankfully X has this X-cellent little feature (first and only pun I promise) that allows you to easily fix it. Essentially I added some panning configuration to each monitor which told X that, while the logical monitor could exceed each individual monitor’s resolution, it could not display windows in areas that I couldn’t see. The easiest way to set this up was right within my graphics settings:

just set the panning on each monitor to be the native resolution and you should be set. Alternatively you can do this within xorg.conf (usually located at /etc/X11/xorg.conf) by adding “@AxB” (where A and B are your resolutions, i.e. @1360×768) to your metamodes option in your screen section. For more information hit this link.




I am currently running a variety of distributions, primarily Linux Mint 17.
Previously I was running KDE 4.3.3 on top of Fedora 11 (for the first experiment) and KDE 4.6.5 on top of Gentoo (for the second experiment).
Check out my profile for more information.

Portage drops the canoe, crushing my Gentoo installation

October 13th, 2009 No comments

In the process of migrating to KDE as my desktop environment (selected as I have no experience with the newest versions, and I want an entire desktop environment as opposed to just a window manager) I decided to use the fateful eselect profile utility.

Gentoo has a system profile selector, where you can choose the Portage profile that best suits your environment and needs for the computer. My existing profile was default/linux/amd64/2008.0, and I decided to switch to default/linux/amd64/10.0/desktop. I then ran emerge –update –deep –newuse world to completely rebuild and update packages accordingly.

Bad idea.

Portage indicated that I had hundreds of dependency conflicts and refused to update or install additional packages, no doubt aggravated by my use of “autounmask” and Portato’s dependency resolver. The most visible problem was Ekiga depending on GTK+ 2.6, which depends on GNOME 2.26, which itself depends on Ekiga. It was a giant circular mess that left me unable to resolve dependencies. I tried all the traditional fixes, including depclean and trying to reset my package.keywords file.

Faced with an intermittently working desktop, I flattened and reinstalled the system last night and am continuing to get things back up in working order, this time with the QT libraries enabled. (KDE is currently compiling – I’m using twm, the default X window manager, to run a web browser.) A few things I noticed this time around:

  • Don’t necessarily put a whole ton of USE flags in your /etc/make.conf file at first. Portage is pretty good at telling you if a flag is required for a package, and you can always recompile something if you need to.
  • In the latest amd64/10.0/desktop profile, X.org comes with version 1.6. I had no end of difficulty getting an xorg.conf file created with X -configure – it would start and load with only a black screen. I ended up running X.org using startx, then using nvidia-config to generate a base file.
  • evdev (for input device support) works great, provided you have hal and dbus USE flags and the appropriate daemons are started. I didn’t even have to touch the input device section of xorg.conf.
  • Select your system profile first, before changing it will cause grief!



I am currently running various *BSD variants for this Experiment.
I currently run a mix of Windows, OS X and Linux systems for both work and personal use.
For Linux, I prefer Ubuntu LTS releases without Unity and still keep Windows 7 around for gaming.
Check out my profile for more information.