I noticed this, when running totem under an EXA "accelerated" environment. This is a cut and paste from the gnome bugzilla, where I fist suspected xvimagesink of gestreamer to be the cause of the bug: "Totem is currently unusable for me, when running a setup with EXA and the composite extension enabled, becaus everytime somethink covers the totem window, the video is hidden in that part. Problem is, that for example gaim causes this effekt for the whole desktop when hiding the gaim window. Testing with xine and mplayer (both also using the XV extension) don't show this effect. Steps to reproduce: 1. run a xserver with EXA and Composite Extension 2. gst-launch-0.10 videotestsrc ! xvimagesink 3. move anoterh window over the window of the xvimagesink and move this window away 4. move xvimagesink Actual results: on step 3. the part of the xvimagesink window, that was hidden by the other window is not redrawn with the contents of the videotestsource. Moving the window make the contents visible again/completly Expected results: in step 3. the xvimageink window should be completly refreshed Does this happen every time? yes" Basicly I just get parts of the unterlying window/desktop shown in the video window, when the covering window is removed from the xvimagesink window. So after a reply from Jan Schmidt I tested again and ran without merged framebuffer enabled. There I noticed two things: 1. The gstreamer bug was gone 2. The system felt much better 2. means, that when running with merged framebuffer (at max. 3080x1050) I had to run xcompmgr, to get an evnvironment, I could work in, this was not necessary in the 1680x1050 case without merged framebuffer.
(In reply to comment #0) > I noticed this, when running totem under an EXA "accelerated" environment. This > is a cut and paste from the gnome bugzilla, where I fist suspected xvimagesink > of gestreamer to be the cause of the bug: > > "Totem is currently unusable for me, when running a setup with EXA and the > composite extension enabled, becaus everytime somethink covers the totem > window, the video is hidden in that part. Problem is, that for example gaim > causes this effekt for the whole desktop when hiding the gaim window. > > Testing with xine and mplayer (both also using the XV extension) don't show > this effect. > Then what makes you think this is a driver bug? if these other Xv apps work fine, wouldn't that indicate totem is to blame? Are you using autopaint for the colorkey or is the app doing it? Also with composite, make sure the colors are actually the same and not a composited color because the overlay will only paint on the color of the key. > Steps to reproduce: > 1. run a xserver with EXA and Composite Extension > 2. gst-launch-0.10 videotestsrc ! xvimagesink > 3. move anoterh window over the window of the xvimagesink and move this window > away > 4. move xvimagesink > I'm not quite sure I follow. > > Actual results: > on step 3. the part of the xvimagesink window, that was hidden by the other > window is not redrawn with the contents of the videotestsource. Moving the > window make the contents visible again/completly > > Expected results: > in step 3. the xvimageink window should be completly refreshed > > Does this happen every time? > yes" > > Basicly I just get parts of the unterlying window/desktop shown in the video > window, when the covering window is removed from the xvimagesink window. > > So after a reply from Jan Schmidt I tested again and ran without merged > framebuffer enabled. There I noticed two things: > > 1. The gstreamer bug was gone > 2. The system felt much better > > 2. means, that when running with merged framebuffer (at max. 3080x1050) I had > to run xcompmgr, to get an evnvironment, I could work in, this was not > necessary in the 1680x1050 case without merged framebuffer. > Of course everything is going to be much slower at 3080x1050! You've doubled the size of an already big the desktop. These chips only have so much bandwidth available.
(In reply to comment #1) > Are you using autopaint for the colorkey or is the app doing it? Yes, I suspect that's the problem (because it's traditionally done to the root window, conflicting with the compositing manager) vs. apps that draw the colour key themselves. The former should be fixed when building the xf86-video-ati git master branch against the xserver git master branch. > > So after a reply from Jan Schmidt I tested again and ran without merged > > framebuffer enabled. There I noticed two things: > > > > 1. The gstreamer bug was gone If by that you mean the above, that's weird, as it's not related to MergedFB at all. Maybe you're referring to the video overlay not being visible on one head, which is a hardware limitation. > Of course everything is going to be much slower at 3080x1050! You've doubled > the size of an already big the desktop. These chips only have so much > bandwidth available. I doubt that's the whole story, though. The radeon driver used to set the EXA coordinate limit to 2048 even on R300 cards where it only uses the 2D engine, which supports up to 8192. Again, that's fixed in the xf86-video-ati git master branch. Also, EXA performance should generally be much better with the xserver git branches server-1.3-branch or master.
Ok, it was an old version of the radeon driver (the version from debian unstable). So I compiled the driver from a git checkout and well, the bug is gone, but I wouldn't consider the situation an improvement. While with XAA everythink work beautifully and quite fast (k, compositing is dog slow), the EXA tests feel sluggish, whether xcompmgr is running or not. What is more, when running with EXA enabled, the display freezes when terminating the X Server. With XAA, I can run several cycles (inlcuding 3D and compositing) in between. I only considered EXA, because the compositing features appealed me. They looked like the only way to get at least some nice looking grafics, as I cannot use beryl/compiz (my desktop is for many times 3080x1050 and a desktop being screwed from 2650 onward is ...)
(In reply to comment #3) > Ok, it was an old version of the radeon driver (the version from debian > unstable). So I compiled the driver from a git checkout and well, the bug is > gone, but I wouldn't consider the situation an improvement. While with XAA > everythink work beautifully and quite fast (k, compositing is dog slow), the > EXA tests feel sluggish, whether xcompmgr is running or not. > > What is more, when running with EXA enabled, the display freezes when > terminating the X Server. With XAA, I can run several cycles (inlcuding 3D and > compositing) in between. I only considered EXA, because the compositing > features appealed me. They looked like the only way to get at least some nice > looking grafics, as I cannot use beryl/compiz (my desktop is for many times > 3080x1050 and a desktop being screwed from 2650 onward is ...) > There is no EXA composite acceleration on r300 and above anyway, so you won't be gaining much. Even if there was, it would be limited by the 3D engine as well.
So what remains is, that before I will see nice effects on my dualhead setup, I will have to wait and hope, that someone finds a way to work around the 2650px limit of the 3d engine. When this is done, I could use beryl/compiz to get a nice and shiny desktop. Apart from that I changed the summary, reflecting the hang I noticed, when activating EXA on the r300.
Can you log into the machine remotely after the hang? If so, is the X server still running? Is there anything interesting about the hang in the X server's log file or stderr output or in the kernel output? If in doubt, please attach (as opposed to paste) all of them as well as xorg.conf.
Created attachment 9381 [details] Xorg.0.log of "startx -- -layout home" and a final STRG-ALT-BACKSPACE
Created attachment 9382 [details] The xorg.conf used for the test
I asume, that you want to know whether the kernel is still responsive (by logging in via ssh). I had no computer handy to test that - but the kernel still runs, as I can shutdown the notebook by pressing the power button, that in turn activates the normal shutdown sequence via ACPI. So the kernel works. I tried to run the server with "-logdebug 20", but the resulting logfile (see attachment) is not too helpfull I think. This logfile resulted from pressing STRG-ALT-BACKSPACE while in X. This caused all clients to shutdown, but did not shutdown the server, which blocked the keyboard. The test was done with "startx -- -logdebug 20 -layout home" Another thing I tried is switching to console and shutting down the server via a SIGTERM worked as expected. The lock only happens, if I run a glx programm before I try to shutdown.
(In reply to comment #9) > I asume, that you want to know whether the kernel is still responsive (by > logging in via ssh). Right, and whether the X server is still running. > I tried to run the server with "-logdebug 20", but the resulting logfile (see > attachment) is not too helpfull I think. Anything in X server stderr or kernel output? > The lock only happens, if I run a glx programm before I try to shutdown. Which version of Mesa do you have? What kind of GLX apps did you try?
The first test happend with the versions from debian (sid). I tested again with the git versions of libdrm, the ati xorg driver and mesa. The base package (xserver-xorg) shows 7.1.0 as version.
I can't reproduce this anymore (running more-or-less mesa git and git xorg-driver-ati) - so I'm closing this bug as fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.