Xorg bugs using QT apps and radeon drivers

Hi,

Trying to run QT-based apps to process photo, I encountered two annoying bugs.
First I got graphics corruption when scrolling in Digikam albums (pictures already on screen get randomly cut and duplicated in blocks, newly displayed pics are fine).
Second, in Qtpfsgui/Luminance, loading hi-res photos (4000 x 3000) causes the X server to eat 100% CPU during few seconds (no X screen update occurs during this time -- kernel still works perfectly). I tried on stable (Qtpfsgui) and head (Luminance), but the slowdown is directly related to the pixmap display, working with CLI is fine and with the GUI, all processings run correctly and the server freeze at the end, when result is sent to screen. Xorg complains about bad drawable/windows, and sometimes prints an hypothesis about a potential infinite loop during the freeze:

I didn't find any posts or patch related to these problems.

* Configuration:
FreeBSD 8.0-STABLE AMD 64, standard config with vesa console driver. Running on Intel Core 2 with 4GB of RAM, and an ATI RADEON HD 4850 graphics adapter.

* Environment:
The first happened both with Xorg 7.4 and 7.5. No problem with "vesa" driver, bug occurs only with "radeon" and "radeonhd" drivers when acceleration is enabled. (I upgraded all involved packages after update with portupgrade "-R" option).
I didn't used Luminance on Xorg 7.4, however switching between drivers has no effect.
Enabling/disabling compositing also had no effect in both cases.
xorg.conf is the default one (no file at all, or using "Xorg -configure" results and changing just the driver line for "radeonhd" and "vesa" drivers).
Running Qt with the raster graphics system instead of native one results in lot of errors about XSHM on stderr and windows are shown but not drawn). Tried with Area51 QT version, same results.

I don't know what else to try.

Thanks for your support,


Fred

I have also noticed some small issues running QT on xorg 7.4/7.5 with a Radeon HD 2400 PRO. Currently i only have one QT application that i use (sqliteman), and i often get areas of the application where it is not redrawn correctly and areas of corruption when switching tabs or scrolling.

This seems to happen more with the Clearlooks theme enabled and less with the Windows theme. I might just be imagining that however.

I didn't correlate this with a problem with xorg or a driver, and assumed it was an issue with the application. But a driver issue makes sense.

infinite loop

I've got a similar issue. X hangs, chews up progressively more CPU, and the PID can't be killed. Ctrl_alt_bksp does not work. Hard reboot required, which necessitates RAID1 rebuild since root wasn't dismounted properly. :-(

This problem so far has mostly occurred with Kopete and Pidgin. This last time upon startx before KDE loaded.

Once or twice the following was logged as the last line in Xorg.0.log:

Googling suggests a problem with accelerated 3D graphics and/or KDE desktop effects. I haven't seen a posting yet with a true solution. I'm not opposed to trying to disable these features 1 by 1 in hopes of finding that solution, but I fear what I might break.

What will I be missing if I disable KDE dektop effects? And how would I toggle them from command line vs gui?

From xorg.conf:
If I commented out dri & dri2, is there anything I might break beyond repair? Or are they the wrong dartboard?

Recently upgraded Xorg to 7.5 from 7.4, and KDE to 4.4 from 4.3. The problems with X intermittently happened before the upgrade. Now seem more common afterward. Im on FBSD 7.2.

If I lose 3D graphics, I probably wont care. No gaming here. Text processing, Firefox (flash enabled), basic stuff..

If you do not want 3d acceloration comment out "glx" line.

Defre said:

Enabling/disabling compositing also had no effect in both cases.
xorg.conf is the default one (no file at all, or using "Xorg -configure" results and changing just the driver line for "radeonhd" and "vesa" drivers).
Running Qt with the raster graphics system instead of native one results in lot of errors about XSHM on stderr and windows are shown but not drawn). Tried with Area51 QT version, same results.

Click to expand...

Avoid radeonhd, try just radeon.

Do you have WITHOUT_NOUVEAU=yes in /etc/make.conf? That will let you get the latest MESA.

infinite loop

I came across a post while googling, and an xorg developer more or less blamed the infinite loop problem on the driver. I downgraded xf86-video-ati to version 6.12.4, which is the version in cvs just before the bump to Xorg7.5 version. X is now using acceleration method "XAA", versus "EXA" before the downgrade. Didn't happen to see any other differences in Xorg.0.log stand out.
Bottom line is it seems to be stable now. Though graphics appear to be slightly slower, and X process uses a bit more CPU when resizing windows etc. But stable is stable.
Is it worthwhile to take the info Ive got and submit it to a developer or port maintainer?

Thank you qsecofr, from your post I got the idea of just to change my xorg.conf to "XAA" with
Option "AccelMethod" "XAA"
it is slower but it seems more stable by now...

cuq said:

Thank you qsecofr, from your post I got the idea of just to change my xorg.conf to "XAA" with
Option "AccelMethod" "XAA"
it is slower but it seems more stable by now...

Click to expand...

What video card do you have?

from dmesg:

cuq, please share a snippet of your xorg.conf so the rest of us can see which section you've coded it in. thx

qsecofr said:

cuq, please share a snippet of your xorg.conf so the rest of us can see which section you've coded it in. thx

Click to expand...

AccelMethod goes in the Device section. See radeon(4x).

qsecofr said:

cuq, please share a snippet of your xorg.conf so the rest of us can see which section you've coded it in. thx

Click to expand...

yes, of course sorry...


I left every other Option in xorg.conf as it were...
I can post the whole file if you ask...