While watching something large moving on the screen (movie, big window...) i can notice some kind of tedious effect. While watching fast sequences of a movie, it appears as three or four thin horizzontal lines, but when moving windows on the desktop it looks more like the edges are flickering. I will attach some screenshots i took to clarify the problem, one is taken during a video playback, one is taken while moving a windows without desktop effects enabled and the last is taken with compiz. I have a Fedora 7 system with: xorg-x11-server 1.3.0.0 xorg-x11-drv-i810-2.0.0 on an Intel DG965WH motherboard (g965 integrated video).
Created attachment 10374 [details] movie screenshot
Created attachment 10375 [details] compiz screenshot
Created attachment 10376 [details] no compiz screenshot
Hm, I haven't seen this on my DG965OT (same graphics chip). Can you try with a more recent driver, or better yet use the latest code from the git tree?
The problem is still there with xorg-x11-drv-i810-2.1.0
would you please add the your configuration and x.org log file.
Created attachment 11811 [details] xorg.conf
Created attachment 11812 [details] xorg.log
I guess reporters of bug #12648 and #12633 have the same problem as me, but with different hardware
*** Bug 12648 has been marked as a duplicate of this bug. ***
*** Bug 12633 has been marked as a duplicate of this bug. ***
Sounds like this is a common problem, so I'm marking the others as DUPs and adding it to the blocker list for 2.2.
*** Bug 9932 has been marked as a duplicate of this bug. ***
The strange issues in the screenshots are a result of gnome-screenshot using gdk-pixbuf, which does a series of getimages to capture the drawable's contents instead of a single getimage. To clarify: the moving window issue you're seeing, do you mean that you get frames displayed which look like (say, moving right to left): +---------------+ | | | | | | | | | | +---------------+ That would be expected unless you're running a compositing manager which synchronized its rendering to vblank. Similarly for movies on 965 currently, which is what the duplicate bugs reported were about.
(In reply to comment #14) Indeed, the tearing which I get on my Thinkpad X61 (Intel 965GM/X3100) looks precisely like a problem with syncing to vblank. However I am not sure it is a fault of the window manager I use (WindowMaker). I've never had this problem before with any notebook I owned (two sony Vaios and one Thinkpad X11). I play back movies there using mplayer, outputting its video to Xv extension. On my current notebook, I've even tried using driconf to create the .drirc file which forces all direct rendering applications to sync to vblank (vblank_mode = 3), but to no effect. The tearing is still there. Plus there is a curious effect - if I run glxgears with this setting (vblank_mode=3), I do not see any gears turning at all, and after a while get following output: "do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. 3 frames in 6.2 seconds = 0.485 FPS" It appears as if VBlank interrupts are not being emitted at all!
I have an additional information on this bug. It disappears, on my system, whenever I connect my Thinkpad X61 to an external monitor! I have now confirmed it: when running glxgears with (vblank_mode = 3) in .driconf on the external monitor (Samsung SyncMaster 959NF), I get no error messages, with the output being 60.0 FPS (where 60 is the refresh rate the screen is current set to). And I can watch movies in mplayer without any screen tearing, using "xv" for video output. When I run glxgears having switched back to the internal LCD panel of Thinkpad X61, I get the error message do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. 3 frames in 6.2 seconds = 0.485 FPS described below. Something is clearly going wrong specifically with reading off vsync interrupts off the internal LCD panel of Thinkpad X61! Which part of X.org is responsible for that - xserver, or intel driver, or..? (In reply to comment #15) > (In reply to comment #14) > Indeed, the tearing which I get on my Thinkpad X61 (Intel 965GM/X3100) looks > precisely like a problem with syncing to vblank. However I am not sure it is a > fault of the window manager I use (WindowMaker). I've never had this problem > before with any notebook I owned (two sony Vaios and one Thinkpad X11). I play > back movies there using mplayer, outputting its video to Xv extension. > On my current notebook, I've even tried using driconf to create the .drirc file > which forces all direct rendering applications to sync to vblank (vblank_mode = > 3), but to no effect. The tearing is still there. Plus there is a curious > effect - if I run glxgears with this setting (vblank_mode=3), I do not see any > gears turning at all, and after a while get following output: > "do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. > Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset. > 3 frames in 6.2 seconds = 0.485 FPS" > It appears as if VBlank interrupts are not being emitted at all! >
remi, would you please post your log file and xorg.conf file?
Remi, unless you're running a git version of Mesa, sync to vblank won't work on 965 (there have also been some bugs in that area which mean a new version of drm is also required). Can either you or filippo give those a try and see if things work? I implemented and tested that awhile back, so afaik it should be working fine.
Created attachment 13597 [details] xorg.conf file
Created attachment 13598 [details] Xorg.0.log file
(In reply to comment #17) > remi, would you please post your log file and xorg.conf file? Sure. Posted.
(In reply to comment #18) > Remi, unless you're running a git version of Mesa, sync to vblank won't work on > 965 (there have also been some bugs in that area which mean a new version of > drm is also required). > > Can either you or filippo give those a try and see if things work? I > implemented and tested that awhile back, so afaik it should be working fine. I used to run the latest stable versions of both Mesa and X. A week ago I compiled git checkouts of mesa, drm, xf86-video-intel and xserver and upgraded to them. The bug is stil there, just like it used to be - screen tearing during any fast update of the screen, particularly when playing movies in mplayer. What changed is the behaviour of glxgears - from the behaviour I described above (the gears not appearing at all) it changed, after the upgrade to git checkouts, to the following: the gears do appear and do rotate, but in a very broken fashion (rendering corruption) and the FPS is varying randomly: 271 frames in 5.0 seconds = 54.176 FPS 304 frames in 5.0 seconds = 60.795 FPS 264 frames in 6.9 seconds = 38.295 FPS 308 frames in 5.0 seconds = 61.591 FPS 290 frames in 7.0 seconds = 41.692 FPS My xorg.conf and xorg.0.log files are posted above.
I'm increasing the priority as many i965 users are suffered, though it's working fine on my i965 system.
For 965GM this requires a recent Mesa. In addition (including on 915), this requires some DRM fixes, so it's really a DRM bug. Removing from the 2.2.1 blocker and re-classifying as a DRI bug.
(In reply to comment #24) > For 965GM this requires a recent Mesa. In addition (including on 915), this > requires some DRM fixes, so it's really a DRM bug. Removing from the 2.2.1 > blocker and re-classifying as a DRI bug. I am on my Thinkpad X61(965GM) running a very recent (3-feb-2008) git checkouts of mesa/drm, mesa/mesa, xorg/xserver and xorg/driver/xf86-video-intel. I still get this bug. What I can't understand is why this image tearing goes away when I connect to an external monitor. It appears only when I use internal LCD screen of the notebook.
Even upstream git is broken at this point. The fact that it works on the external display is just luck, given that we don't reprogram the full set of interrupt handling registers correctly at this point. Some users have reported that things work until they do a suspend/resume cycle. Depending on the machine, that may modify the interrupt registers just enough to make things fail.
Any updates on this issue? Anything I can do to help (testing, etc)? I'm willing to do anything I can since this issue is a major blocker for me (G35-board was supposed to be used as a base for HTPC, but it is not currently possible due to Xv-tearing)...
Does anyone know what is going on with this bug? I'm much in the same situation as Mikko, wanting to build a media PC. But if the linux drivers can't do it and I have to run Windows anyway, I might as well get a cheaper AMD solution :(. So for me, this very much is a selling point.
I think there are actually a few bugs here, we should separate them out: 1) tearing while playing movies 2) tearing while drawing with 3D applications that are sync'd to vblank (compiz, glxgears, etc.) 3) tearing while using 2D applications It sounds like most people in this bug are really concerned with (1), so I'm going to re-classify it as such. If you're seeing problems with (2) or (3), please file separate bugs for each, so we can track those problems (which have different solutions) separately. I think (1) will be solved for 965 users by using the overlay port and integrating Maxim Levitsky's patch to add overlay support to the driver for 965 chipsets (we thought this had been removed from the hw, but Maxim proved us wrong! :). Thanks, Jesse
Ok, this should be fixed by commit 5915c75422c5277d530e7f8ecbdfe94654706efd if you use the overlay Xv port. Please test and make sure it works for your HTPC applications... Composited, textured video stuff belongs in bucket (2) from comment #29; the commit above does nothing about that problem.
I confirm, problem (1) is solved by using the overlay port enabled with Maxim Levitsky's patch. I understand nothing can be done for (3) (see Comment #14 ), this leaves number (2) for 3D applications and textured video stuff (at least for me...).
Well, actually we can do something about (3), we need to resurrect my Xsync->DRM patch (http://lists.freedesktop.org/archives/xorg/2006-March/013717.html); it should help. As for problem (2) (gl vblank waits), if you're seeing problems there please file a separate bug, unless it's a DUP of #14682. Thanks, Jesse
Wait! This is not fixed for me yet. I recompiled mesa, drm and xf86-video-intel with latest git checkouts of each. I then recompiled mplayer. "mplayer -vo xv" still produces the tearing. "mplayer -vo xover" doesn't work. So Xv is still broken for me. Am I missing something stupid?
Well, don't mark it as WONTFIX! :) If you can't make it work reopen it instead. I think what you want is mplayer -vo xv port=1 or something to select the overlay port rather than the textured video port. -vo xover is just for tdfx according to the mplayer man page.
Remi, i have a DG965WH motherboard and mplayer works just ok, with mplayer -xo xv:port=89 . No tearing. Still there are apps that don't let you choose the xv port to use, but always use the first one. It would be useful to have an option to set the default xv port. As for problem (2), I can't be help until compiz works in fedora rawhide (wich has both the latest xorg and the latest intel driver i believe). Right now enabling compiz gives a completely black screen (except for the cursor). On the other hand using the metacity compositor still gives sync to vblank problems...
While I'm happy that mplayer now works cleanly with the fix, the fix seems more an interim solution than a long term fix. Is there anything that can be done as a more absolute fix or do you see that as coming under bug 3 (tearing with 2D applicatons)?
> I think what you want is mplayer -vo xv port=1 or something to select the > overlay port rather than the textured video port. -vo xover is just for tdfx > according to the mplayer man page. I confirm that the bug is now fixed for me as well. What I had to do is first to run 'xvinfo' to find out the port number (82, in my case) for the overlay Xv port and then run "mplayer -vo xv:port=82". Thanks, excellent job. But is there any way to have bug (3) fixed some time in future? I use a lot of 2D apps: scummvm, dosbox, various other emulators. Tearing really gets in the way there.
Yeah, for 2D tearing there are some things we can try. If you're running a composited window manager, it can take care of making sure window updates don't tear (once we get the 3D stuff fixed), but if you're running a 2D app directly under an older window manager, you'll need something like the Xsync extension to be wired up to the DRM vblank events. The latter isn't much work, but also not as generally useful as the former.
(In reply to comment #38) > under an older window manager, you'll need something like the Xsync extension > to be wired up to the DRM vblank events. The latter isn't much work, but also > not as generally useful as the former. > But don't textures and 3D apps bypass window manager at all? So it would be up to the driver to properly sync to blank instead of relaying on older/newer window manager. And also, this bug should not be marked as fixed if the fix means to avoid textured overlays.
Yes, with current code textures and direct rendered apps will bypass compositing window managers, but with DRI2 that will no longer be the case, so the window manager could help. And yes, driver support will still be needed. As for textured video tearing, please file a separate bug for that; I don't like to see bugs that cover multiple problems.
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.