Compiz on latest dri, mesa, rdr and ati driver

[Mr_Ed]

I am testing Fedora rawhide (f11).

With the latest dri, mesa and open source xorg-x11-drv-ati driver, I am unable to use compiz anymore. When I enable compiz (a.k.a. desktop-effects) it completely locks-up the system and I am forced to do a hard reboot.

The F11 test version did have a few other problems but not this one. However it seems that current packages only make thing worse and although I know that it is only in a "development" state, it really gives me the impression it is going in the wrong direction at the moment.

I am worried that, once f11 is finally coming out, the current issues with the mesa, dri2, rdr and ati oss driver will not be solved. But that I will be faced with a desktop where only 2d will be usable and no opengl composited desktop is possible.

I'd like to see more information on this forum in this topic about it. Is anyone able to provide it here?

The current information I can find about it is very sparse. And I don't know where to look for it else on the www.

Regards,

Eddie.

[bridgman]

This is the first time all these packages have come together and worked together at all, ie the start of integration testing.

The foundation of the driver stack has been redesigned so there is an of "starting from scratch" here. What you are seeing is the "radeon-rewrite" mesa branch (ie a lot of new code plus significant refactoring of existing code) running over a new drm driver with GEM/TTM memory management and kernel modesetting. You can do a search on "radeon-rewrite" for more info about the new code.

Also, here is a link to the recent "test day" announcement :

http://forums.fedoraforum.org/showthread.php?t=218372

I believe the devs are still looking for feedback on the new code, so your inputs can be very useful. From skimming the test results, it looks like Compiz was generally running OK but video playback under Compiz often had problems.

From a graphics POV, one of the main goals of F11 is to get the graphics stack to the point where Compiz can be enabled by default, so it's very unlikely that you would get stuck with a 2D-only environment. I think you would see F11 rescheduled before that happened.

EDIT - I just re-read your email; maybe you are saying that the code has gotten worse since the "test day" release a couple of weeks ago ?

[d2kx]

Will the final F11 release still use radeon-rewrite and the GEM/KMS-enabled driver or is this just during the development cycle so the OSS devs can try out their code? Which card do radeon-rewrite/GEM+KMS support at the moment (up to R5xx or R7xx)?

[Mr_Ed]

I just re-read your email; maybe you are saying that the code has gotten worse since the "test day" release a couple of weeks ago ?

That's right. And I have raised a couple of bug reports for it in redhat's bugzilla. But the progress on those is very slow, close to nothing yet. Meanwhile, I've been updating mesa and drivers whenever there was a newer version for it and all the time I have seen only a degree instead of an improvement in it.

Hence my concern.

Regards,

Eddie.

[bridgman]

Will the final F11 release still use radeon-rewrite and the GEM/KMS-enabled driver or is this just during the development cycle so the OSS devs can try out their code? Which card do radeon-rewrite/GEM+KMS support at the moment (up to R5xx or R7xx)?

I believe the intention is to ship with all the new code. Without all the new bits, you don't get Redirected Direct Rendering (flicker-free OpenGL on a composited desktop) and without that it's not practical to enable the compositor by default.

The current code supports up to 5xx, but we have shifted direction a bit on our 6xx/7xx 3d work to line up immediately with radeon-rewrite rather than finishing the 3d driver based on old code then porting to radeon-rewrite and the new APIs later. I haven't looked at 3d progress vs F11 schedule so not sure what the chances are of getting 6xx/7xx support into F11. For now I would assume it won't happen. Worst case though is that 6xx/7xx would boot up with KMS disabled and run with the user modeset / non-mm code paths, as it probably does today.

That's right. And I have raised a couple of bug reports for it in redhat's bugzilla. But the progress on those is very slow, close to nothing yet. Meanwhile, I've been updating mesa and drivers whenever there was a newer version for it and all the time I have seen only a degree instead of an improvement in it.

Got it. I think what's happening here is that most of the bug reports map onto a small number of non-trivial problems further down the stack, and that's where the work is being done. Once that work is finished, I imagine all the bug reports will get revisited at more or less the same time, so progress will probably come in a big lump rather than progressively.

Put differently, the reported problems aren't the kind of independent ones you can "work through one at a time".

[Mr_Ed]

I would like to know more about the current work-in-progress. Who can tell us more about it? Is there a blog or such? I know there is work-in-progress because I installed at least 4 driver updates that have come out after the test day.

[bridgman]

Dave Airlie's blog is probably the best source for the radeon-rewrite work and associated drm efforts :

http://airlied.livejournal.com

For Fedora progress in general, the News site is probably best. There's a fairly detailed weekly update posted there :

http://forums.fedoraforum.org/forumdisplay.php?f=17

I haven't found anything specific to "Fedora graphics" yet.

[Mr_Ed]

From the latest Fedora news http://fedoraproject.org/wiki/FWN/Issue172:

Adam Williamson reported on his progress in evaluating whether important bugs reported in the X driver Test Days are fully represented on the Fedora 11 release blocker bugs list. The nouveau maintainer, Ben Skeggs, has already reviewed all nouveau bugs. Review of intel and radeon bugs are in process together with the regular triagers for these components, Matej Cepl and Francois Cami.

[Mr_Ed]

Just a little update. I was able to get desktop-effects up and running again.

When compiz-fusion is enabled using fusion-icon, the screen is not correctly updated and error "settexbuf 1280x1024@4 5120 targ 84f5 format 1401" is in ~/.xsession-errors.

For instance: When open terminal and typing in it, nothing is
show on screen or is corrupted until terminal window is moved. But other windows like browsing files or folders in nautilus show this behaviour too.

And errors like below are constantly being logged in ~/.xsession-errors

ettexbuf 1280x1024@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x25@4 5120 targ 84f5 format 1401
settexbuf 1280x1024@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 37x37@4 192 targ 84f5 format 1401
settexbuf 1280x25@4 5120 targ 84f5 format 1401
settexbuf 37x37@4 192 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 1280x1024@4 5120 targ 84f5 format 1401
settexbuf 1280x25@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 37x37@4 192 targ 84f5 format 1401
settexbuf 1280x1024@4 5120 targ 84f5 format 1401
settexbuf 1280x25@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 37x37@4 192 targ 84f5 format 1401
settexbuf 170x170@4 704 targ 84f5 format 1401
settexbuf 1280x1024@4 5120 targ 84f5 format 1401
settexbuf 1280x33@4 5120 targ 84f5 format 1401
settexbuf 37x37@4 192 targ 84f5 format 1401
settexbuf 170x170@4 704 targ 84f5 format 1401

I removed the driconf package and all related .drirc files.
I also removed all compiz settings

When I don't use the "fusion-icon" program to enable compiz but instead use the "desktop-effects" application, the problem does NOT appear.

When using "desktop-effects" to enable compiz, the garbeled screens are gone and also I do not get the settexbuf errors in the ~/.xsession-errors log.

I do not know what the difference is between enabling compiz through
"fusion-icon" and "desktop-effects" but it clearly makes a big difference.

[Mr_Ed]

when I enable desktop effects, my X session crashes and I am being thrown back to the login screen.

In ~/.xsession-errors.old the following is logged:

gnome-panel: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
Window manager warning: Fatal IO error 11 (Resource temporarily unavailable) on
display ':0.0'.
xfce4-settings-helper: Fatal IO error 11 (Resource temporarily unavailable) on
X server :0.0.
seapplet: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
mail-notification: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.
nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
bluetooth-applet: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.
gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily
unavailable) on X server :0.0.
gpk-update-icon: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.
applet.py: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.
gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on
X server :0.0.
gnome-terminal: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.
gnome-power-manager: Fatal IO error 11 (Resource temporarily unavailable) on X
server :0.0.

(gnome-panel:4764): GLib-GObject-CRITICAL **: g_object_run_dispose: assertion
`G_IS_OBJECT (object)' failed

(gnome-panel:4764): GLib-GObject-CRITICAL **: g_object_run_dispose: assertion
`G_IS_OBJECT (object)' failed
gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server
:0.0.


And in /var/log/Xorg.0.log.old:

Backtrace:
0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812e40b]
1: /usr/bin/Xorg(xf86SigHandler+0x9e) [0x80c0e0e]
2: [0xc2c400]
3: /usr/lib/dri/r300_dri.so(radeonDestroyBuffer+0x34) [0x429d2d]
4: /usr/lib/dri/r300_dri.so(radeonDestroyContext+0xf4) [0x44bda0]
5: /usr/lib/dri/r300_dri.so [0x423f32]
6: /usr/lib/xorg/modules/extensions//libglx.so [0x19b099]
7: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x91)
[0x18f431]
8: /usr/lib/xorg/modules/extensions//libglx.so [0x18f857]
9: /usr/bin/Xorg(CallCallbacks+0x56) [0x808b036]
10: /usr/bin/Xorg(CloseDownClient+0x67) [0x8080fb7]
11: /usr/bin/Xorg(Dispatch+0x1d8) [0x8086698]
12: /usr/bin/Xorg(main+0x3ad) [0x806bb0d]
13: /lib/libc.so.6(__libc_start_main+0xe6) [0xa8a8e6]
14: /usr/bin/Xorg [0x806afa1]

Fatal server error:
Caught signal 11. Server aborting

It doesn't crash all the time when I enable desktop-effects.

After four times logging in again and trying to enable desktop effects, it suddenly didn't crash. And all worked fine.

But when I reboot and log back in again it starts crashing again.

Regards,

Eddie.