ATI driver woes

There are no less than 3 choices for a driver when you have an ATI graphics card, it seems. This would be a good thing if any of them actually worked.

I have an X1250 (which is integrated into a 690G-chipset motherboard). The “radeonhd” driver works but doesn’t support TV-out, XVideo acceleration or 3D acceleration and so is really little better than the vesa driver at this stage. The “radeon” (or just “ati”) driver gives me a blank screen (I filed a bug report). The proprietary Catalyst driver (or “fglrx”) works except it is a pain to install (on my homebrew system), all OpenGL programs crash (looks like the opengl library provided with the driver is causing some sort of memory corruption or double-free?), and Xvideo output from MythTV results in a double-image (one on top of the other, as if there’s some sort of de-interlacing issue). Of course XVideo didn’t work at all until I set some option “TexturedVideo” in my xorg.conf file – the only hint I got to do that was the X sever logs; the option wasn’t documented anywhere. In fact, none of the options for the fglrx driver are documented officially.

I’ll also throw in a complaint at this stage about the “/etc/ati/amdpcsdb” file, and the fact that settings it contains silently override equivalent settigns in xorg.conf, so that you end up wondering why changing the xorg.conf file doesn’t appear to have any effect.

Back to the original story. Basically, three drivers just means I’m screwed three ways. I’m trying to build a Home Theatre PC and my only option for watching TV, at this point, is now to install the MythTV frontend on another machine (with integrated Intel video) and watch it on that.

Edit 14/04/2008: I got the double-image problem sorted – it was actually MythTV itself that was causing the issue, the standard de-interlacing filter converts the image into a double-height image with the fields one above the other and this is what I was seeing. It’s meant to then double the frame rate and show the two halves one at a time but for some reason that wasn’t happening. I’m partly to blame here because I’m using a subversion pull of MythTV rather than a released version.

Also, I’m pleased to report there’s been some progress with the open-source ATI drivers. The radeonhd driver made another release (1.2.0) which apparently does nifty stuff like 2D acceleration (still no TV-out, 3D, or Xvideo). Also, by using the latest drm module (latest pre-patch kernel release, 2.6.25-rc9) and switching to the EXA acceleration method I was able to get XVideo working with the radeon driver, which is pretty good, though it still can’t do TV-out, still blanks the screen if anything is connected to the composite output when I start X, and it now also leaves me with a blank screen when I exit X or switch to another VT. Never-the-less it’s great to see some progress on these drivers.


Eclipse cannot “retrieve ‘feature.xml'”, apparently.

I was getting the following error message in Eclipse, when I tried to use the software update (which, for some inexplicable reason, is accessible from the “help” menu):

Error retrieving “feature.xml”. [error in opening zip file]

Other than the fact that it probably shouldn’t have been appearing anyway, what’s particularly galling about this error message is that it offers no clue as to what the f*ck has gone wrong, nor even why it matters. The only visible effect of this error was that the eclipse update websites didn’t appear in the list, and that a dialog with the error message would pop up with just about any action I would take (other than closing the update dialog completely).

Very, very, stupid.

I did what I have increasingly found to be the quickest and easiest method of solving problems such as these: A Google search. It led me to this web page:

…Sure enough, deleting site.xml from inside my eclipse installation directory made the problem magically go away. It turns out that the eclipse CDT (C development tools) zip file which I had downloaded, was actually meant for retrieval via the eclipse updater and not meant to be installed by simply unzipping it inside my eclipse directory as I had done. Clearly the CDT guys are partly to blame for this because they don’t seem to actually provide any other downloadable version.

But… I mean, should the presence of some file in the installation directory really cause such an annoying problem? And if it does, shouldn’t the error message at least attempt to explain what the problem actually is?

Xorg X11R7

It’s funny, the “/usr/X11R6” directory name (and of course X11R6 itself) is such a mainstay that it’s hard to think of changing it, even if technically the new release is R7. I’ve finally moved to it, mainly because my old system decided to die on me recently and I ended up purchasing a new motherboard (Gigabyte again, despite minor annoyances previously, thankfully the onboard audio is not automatically disabled when I plug a PCI card in – hooray…) and processor (Core Duo). The system is much quieter than the old one (those old P4’s ran way too hot, and consequently the fan was always whirring away like a mad thing trying to cool things down a little).

The motherboard has an onboard intel graphics chip; I figured it was either that, or buy a new Nvidia to replace my aging TNT2 (which was AGP anyway and therefore unusable in the new system, which has PCI-Express slots instead). I initially tried the VESA BIOS driver with my old X version (6.8.1) but it just froze the system, and it wouldn’t have been accelerated anyway. So I figured I may as well upgrade to the modular X11R7.2 release.

It all went fairly well (it’s now running, at least) except the lack of build documentation is appalling. I eventually found a shell script which could be used to compile all the modules and therefore yield a working X11R7.2, well in theory anyway; I was missing a few dependencies (for one, xcb, which isn’t part of X, apparently) and even when those were resolved the xserver kept failing to build. Firstly, it’s configure script rejected my attempts to use the most recent versions of Mesa (7.0.1 and 6.5.3); older ones (6.4.2 for instance) caused the build to bomb out in mysterious ways (which didn’t seem Mesa related and which thus kept me scratching my head for a while). No, it turns out that building the server requires one very specific version of Mesa, and that for some obscure reason this fact is not documented, anywhere. Except, now for here. It’s 6.5.2.

Fortunately I was able to download the latest version of the intel video driver and it supported my G33 chipset with no problems, except for lack of 3D acceleration. For that I needed DRI and that meant upgrading my kernel (not such a big deal) and using a git snapshot of Mesa (very annoying, especially as it conflicts with the version used to compile the xserver and thus prevents AIGLX from working).

Also, although it initially worked fine, at some point the intel driver decided that it would ignore all previous convention regarding which resolution to start with and began running in something like 1152 by 768 which is way too short vertically (I use 1280 by 1024 normally) and also, gallingly, not directly supported by my LCD monitor which then needs to stretch the image itself so that it can display it the native 1280 by 1024, causing pixel artifacts and looking generally quite shit. I eventually discovered that using the “PreferredMode” option in the Monitor section of my xorg.conf configuration file could solve the problem, the main issue was that this setting isn’t documented in the man page that comes with the server in R7.2.

Ah well. Now I guess I wait for R7.3 and hopefully I can get AIGLX working…


Bugzilla still doesn’t include “RESOLVED – FIXED” bugs as a default when doing a search. Even when you “find a specific bug” and choose “open bugs”, resolved bugs do not appear in the search results even though the bugs are most definitely NOT closed (and therefore are open).

The real problem here is that people who think they may have found a new bug are going to continue to believe that after doing a search, even if the bug has already been reported and fixed (but not yet released).

Mac OS X and networking

I have a shiny new 15″ MacBook Pro, my first Mac. It’s a great laptop and I only have one major complaint, hardware wise: Only a single button for the trackpad?!! Oh well, I’m going to be plugging in a proper mouse soon anyway. The real issues I’ve been having are with the OS software.

I have a small network connected via a combined ADSL modem/4-port router. I run the router in a mode called “half-bridge” which essentially means that the router forwards all traffic coming up the ADSL link onto the LAN directly, without modification other than de-encapsulating the packets from the PPP link. My NAT server (running linux) therefore listens for incoming traffic on the WAN address as well as its own LAN address. The router must also pick up packets destined for the WAN and forwards them on down the ADSL (PPP) link. Naturally the NAT machine is the only machine that sends packets destined for the WAN: all the other machines on the LAN use the NAT box as a gateway; this allows NATting and traffic regulation etc.

If you already know what the problem is that I’m about to describe, I think you’re doing pretty well. Continue reading “Mac OS X and networking”

The “J” in “AJAX” should have stood for “Java”

Java… more of a standard than a piece of software, I guess, but let’s attack it anyway. The only question, as is often the case, is where to begin… and I’ll constrain myself by not even mentioning Swing (oops, too late).

First, there is the abysmal lack of support for real world file system handling. Like symbolic links, and unix permissions (Is this really coming in Java 7? about time).

Second, the incomplete support for asynchronous operations (any operation which blocks should be interruptible).

Third, and this one will be contentious, “equals” and “hashCode” should not be instance members. You should pass in a functor object which performs those operations to collection classes which need them (that’s not to say there might not be one or more default implementations of these functors).

Fourth, the collections library is incomplete. Why aren’t there utility classes such as JointSet (provides a set interface, backed by two or more real sets)?

Fifth, every object can be synchronized() on. Which means that every single object has a mutex hiding in it – which is a waste.

Sixth, it’s not possible to create a real Java sandbox from within a Java program, which is quite ironic seeing as this is really what Java was developed for (If you want to run some untrusted code, you can set a security manager, sure; but you can’t force a thread to stop running once you have started it. Even the deprecated Thread.stop() method won’t always work). There should be a safe way to stop threads (even if it means restricting what those threads can access/do), and you should really be able to intercept file and gui calls and handle them in any way you want (it shouldn’t just be limited to allowing or disallowing the operation).

Seventh, stupid version numbers. Java 5 – wtf? Java SE 6? Whoever came up with these names & numbers should be reprimanded!

Ah well, I guess that’s enough. For now anyway…

QT’s qmake

Geeezus. There’s a lot wrong with “make” in general and there’s been way too many attempts to fix it; no-one, as far as I can see, has got it right yet. qmake is no exception, but it does in fact manage to be particularly bad.

Firstly, the makefiles that qmake generates can’t do a “make DESTDIR=<whatever> install”, no, that’s too standardised, we couldn’t have that. You have to do a stupid “make INSTALL_ROOT=<whatever> install” instead (DESTDIR has some completely different and somewhat retarded meaning). And that, of course, doesn’t actually work, because the file paths in the makefile are written in such a way that it just doesn’t work. You can fix it by editing the “qmake.conf” file in the QT bundle and add “no_fixpath” at the end of the options listed for the CONFIG variable, before you run qmake. Why isn’t that the default? Considering that “fixing” the path actually borks it, I’m not sure what sort of numbnut came up with the term or the code.

It’s easy to verify this by trying to compile “qca” (QT cryptographic architecture) and installing it in some alternate location. If no_fixpath isn’t set, it doesn’t work, does it? Hello QT developers?

Oh yeah, and qmake has a very limited concept of quoting, but that’s certainly a problem not limited to this particular software package.


Edit: Apparently “no_fixpath” is no longer required in Qt 4.3.1; I’m not sure when it was fixed (it was a problem in 3.3.7). However INSTALL_ROOT is still used instead of (the de facto standard) DESTDIR.