"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"
About this blog

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Most content on this site is licensed under the WTFPL, version 2 (details).

Questions? Praise? Blame? Feel free to contact me.

My old blog (pre-2006) is also still available.

Sun Mon Tue Wed Thu Fri Sat
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, entries_index, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
Broken ATI drivers crashing Ion

This afternoon, in an attempt to make Xdmx work, I decided to dist-upgrade Kat and Xanthe, both of my Debian sid boxes. After upgrading 600-ish packages, suddenly I couldn't start any new xterms. Some investigation showed a font problem, and since a font incompatibility was the reason I started upgrading in the first place, I thought it would help to restart my X server.

That turned out to be nasty, since ion, my window manager, crashed on start up with a rather cryptic message.

>> [72] X_CreateWindow (1) 0: BadValue 
    (integer parameter out of range for operation)

Anyone with some debugging experience will concede that this is not a real pleasure to work with (actually, anyone without this experience will run away screaming seeing this...). Still, I need a window manager to work, so debugging it is...

Googling for this did really not give anything to work on, and looking at the documentation for xlib's CreateWindow function showed that a dozen of values could be bad (though I could not find which values exactly...). Also, there was not really any hint in the error message as to where in the ion source code I should look, so no luck there.

Gdb is your friend

Fortunately, ion is compiled with debugging symbols by default, so [gdb] managed to trap the error where it occured. That is, somewhere around where it occured, since X uses an asynchronous protocol. Looking around the trap location revealed the CreateWindow call that caused the problems. When creating the ion root window, something went amiss.

I had some problems figuring out what exactly happened (even recompiled ion without optimisations, hoping that that would clear things up), but eventually I found that the first call to CreateWindow went perfectly allright, but the second call went awry. Not surprisingly, since it passed a windows size of 0x0. Investigation this further, it appeared that Xinerama returned the presence of two screens, while I only have one monitor connected.

Bad ATI, Bad ATI!

This moved the source of the error from ion to ATI's fglrx driver, which also got upgraded this afternoon. So, for some reason, it was reporting two Xinerama screens, the first having the proper size, the second being empty.

Doing some quick looking around in the xorg log file shows that it detects only 1 attached display, as it should, only for some reason the virtual resolution is set to 1280x800 properly at first, but then to 2560x800 a few lines below. Not really sure what that is supposed to mean.

Rummaging around in my config file reveals I have a few options left from my dual-monitor dabbling, such as DesktopSetup and Mode2. These options used to have no effect if no second monitor was detected, but apparently this changed. To be short, reming the DesktopSetup option solved my immediate problem.


Now, how to make sure this does not happen to me or anyone again? I see two things here. Firstly, ATI should make sure it does not do gibberish things like listing empty Xinerama screens. I'm not sure, but I reckon they might be acting against the Xinerama specifications by doing this (though the offending api, XineramaQueryScreens is a XFree86/Xorg specific extension to Xinerama and does not seem to be documented anywhere...). I've put all this together in a bug report on their unofficial bugzilla, so let's hope they manage to fix this.

Secondly, ion should be a little more defending and ignore Xinerama screens having no width (since taking them for granted will cause ion to violate the X specs and crash...). I'll formulate the problem and send it to ion's mailing list somewhere tomorrow, after I've had some sleep...

0 comments -:- permalink -:- 02:03
Copyright by Matthijs Kooijman