sil2100//vx developer log

Welcome to my personal web page

Hunting for a fglrx bug - X programming

I wanted to share a short story about an irritating bug I have been trying to fix in Ubuntu's compiz, related to the ATI Radeon proprietary closed driver fglrx. I had many context switches during the process, so it took longer than I suspected. This post might shed some light on a strangely specific problem that I encountered.

2012-04-19 19:17

Empty

The bug in mention can be seen on Launchpad LP: #770283 from compiz. Window decorations (title bar, window buttons etc.) did not update on normal usage when the fglrx driver was used. The only way of updating the decorations was to resize the window, on which the decorations magically got redrawn the way they should. But things like focus changes, mouse hovering or title changing - nothing resulted in the decoration update. If you ask me, this is a VERY irritating thing not being able to see what window is currently focused.

At first I thought that maybe compiz was at fault, that maybe it's doing something in a way that confuses the fglrx driver. For that, I had to understand how the decoration drawing mechanism works. The following diagram can briefly sum it up:

Diagram showing the internals of decoration update in compiz

This is a very simplified description, but more or less shows how it's done. Knowing this, there is not much philosophy involved - modifying the original Pixmap in gtk-window-decorator (or any other decorator) should result in the texture being automatically updated.
Whenever a window changes its decoration in any way, the decorator draws the modification to the window's decoration Pixmap. The driver ensures that the change gets propagated to the right GLXPixmap. Damage events (XDamageNotify) telling which parts of the screen should be redrawn were flowing correctly as well, so theoretically nothing was wrong.
So what is the cause of the problem?

It seems fglrx has a problem with propagating changes made to a Pixmap to its corresponding GLXPixmap. So, as a temporary workaround, I proposed hooking up to the compiz decor plugin damage events handler and rebind the texture whenever it changes. This way, on every decorator pixmap modification, compiz will destroy and create a new GLXPixmap and the corresponding texture. A dirty workaround, but works with an unnoticeable performance footprint.

But I wanted to prepare a test application that could isolate the problem, making sure that it's not only compiz specific. This was not an easy task, since I just recently started working on X related code, so my knowledge was almost 0. Also, my OpenGL skills didn't age too well as well (it's been a while!). But by looking into compiz code and reading up the GLX_EXT_texture_from_pixmap OpenGL specification, I was somehow able to reproduce the bug with my simple application.
All that are interested can download the source here: [fglrx-test.c]. Not much to see though, since its just a trivial application made specifically with the purpose of testing if the bug can be reproduced or not. Big thanks to Gord Allott for clearing up some things for me!

A summary of some random things that I learned, which might be useful for others:

As for now, my ugly workaround has been merged into the compiz distro and it'll probably be available to all Ubuntu precise users (12.04) with the nearest SRU (Stable Release Update). After a while, I hope we'll be able to fix the very root cause of the bug. The guys from ATI (AMD) are really helpful, so it might even happen pretty soon!

IMPORTANT UPDATE! Please read my next post regarding the bug mentioned here!