Created attachment 56193 [details] Last 1M lines of Xorg.log When I play a video in vlc using XVideo in fullscreen mode, after some time, ~5 minutes, the video stalles but the sound goes on and as soon as I restore the window size the vieo starts playing again. This only happens with compositing enabled (xfwm4). I did manage to reproduce this with --enable-debug=full. When the video gets stuck, I kill -15'd X when vlc was still in fullscreen and the video was stuck so that the log hopefully contains hints regarding the error at the very end.
Interesting. It's still rendering, but in huge clumps of frames in one batch. The missing link is the compositor, it's not receiving the damage for those frames and so it is posting the fixes of the backing pixmaps onto the scanout. I think in this case we are looking at an xserver XComposite bug, and there is at least one known major bug there where the xserver loses track of damage on the scanout after a modeswitch that was only fixed in 1.12-rc. What does the first line of the log say, i.e. what version of Xorg are you running?
I'm using X.Org X Server 1.11.99.2. I'll update and give it another try.
Nope, X.Org X Server 1.11.99.901 (1.12.0 RC 1) is no good either...
It was worth a shot. Going over the log very carefully, it is simply that the requests to copy the video pixmap onto the scanout stop. Those requests emanate from the compositor, so that would be my next port of call... Is there a chance you can launch xfce4-session from under xtrace and record the interplay between xfce4-wm and X when the video stalls?
Created attachment 56231 [details] xtrace record of xfce4-session Here you go. I hope you can find out sth.
A Clue! 025:<:43a5: 52: XVideo-Request(132,19): ShmPutImage port=77 drawable=0x02800000 gc=0x02800002 shmseg=0x0280000c id=0x30323449 offset=0 src_x=0 src_y=0 src_w=704 src_h=576 drw_x=0 drw_y=0 drw_w=1920 drw_h=1080 width=704 height=576 send_event=false(0x00) 025:>:43a5:Error 11=Alloc: major=132, minor=19, bad=77
I've added some DBG, if you would be so kind... commit b9c83e0b2c42f7657b1854a7cdcbc0407957c382 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jan 27 18:24:01 2012 +0000 sna/video: Add some DBG messages to track the error paths References: https://bugs.freedesktop.org/show_bug.cgi?id=45279 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Rather than --enable-debug=full, you can try setting #define DEBUG_VIDEO 1 in src/sna/sna.h
Created attachment 56236 [details] new Xorg.log with --enable-debug=full Hmm, #define DEBUG_VIDEO 1 didn't show anything relevant in the logs, so I went for --enable-debug=full.
We have an answer, or rather the next step in the chain, [ 13059.572] sna_video_textured_put_image: src=(0, 0),(704, 576), dst=(0, 0),(1920, 1080), id=808596553, sizep=704x576, sync?=0 [ 13059.572] sna_video_textured_put_image: attempting to render to a non-GPU pixmap Ok, I think I know what's going on... I forgot to mark the pixmap as active when rendering as I presumed that it was always going to be the scanout and never disappear. Then the idle reaper came along, declare the pixmap as inactive and destroyed the GPU bo. commit 8f4bae01e39392faa8978090db4cbe28fa00b013 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jan 27 20:28:44 2012 +0000 sna/video: Ensure the video pixmap is on the GPU The presumption that the pixmap is the scanout and so will always be pinned is false if there is a shadow or under a compositor. In those cases, the pixmap may be idle and so the GPU bo reaped. This was compounded by that the video path did not mark the pixmap as busy. So whilst watching a video under xfce4 with compositing enabled (has to be a non-GL compositor) the video would suddenly stall. Reported-by: Paul Neumann <paul104x@yahoo.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45279 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.