As of bug 19635, video tearing has been fixed but only in a non-composited environment. As using compositing is very usual, this is quite a big problem. haihao commented in bug 19635: "Jesse has some commits to eliminate tearing when using composite manager, but he doesn't push them out now." System environment: -- chipset: G45 / ICH10R -- system architecture: 32-bit -- Linux distribution: Debian unstable -- Machine or mobo model: Asus P5Q-EM -- Display connector: DVI -- xf86-video-intel: 4a0d19ef4f210cea9e60c5acc355df03723ef808 -- xserver: 1.5.99.901 -- mesa: 2305642b2e8edcebdc727f1181f7dbfcc78e8028 -- drm: 4a0d19ef4f210cea9e60c5acc355df03723ef808 -- kernel: drm-intel-next 126fd9c96d80260a1f2d8dfc72e444e572bcafb7
I'm not sure who is working on this? (CCing bunch of people)
FWIW, at least compiz and xfwm4 can be configured to unredirect fullscreen windows.
*** Bug 19458 has been marked as a duplicate of this bug. ***
Updated the summary and changed to an RFE. Last patch set went to dri-devel under the subject "Another page flipping update". Basically, compositing managers need a way of making sure their front buffer rendering can occur w/o tearing. This includes composited video. This RFE covers an tear-free glXSwapBuffers implementation that any OpenGL application can use for this purpose. It's possible to do this in other ways, for example through an X extension or something, but that's a subject for another RFE if someone wants to take it on.
Maybe it is stupid but why not enable vsync for the whole composite output? I mean who needs more than 60 fps anywhere? For benchmark reasons there could be an option which disables it which results in video tearing.
I think a lot of compositing managers will choose that option (when they have updated frames to display of course). Right now though there's no good way for them to sync all output. They can block on a given pipe's vblank event, but that's racy, since the compositor process may not be woken up in time or may not finish its drawing in time to draw w/o tearing. So we really need glXSwapBuffers to be sync'd automatically, which allows the compositor (or other GL apps) to prepare a whole frame, swap buffers, and then continue rendering the next frame and not worry about tearing at all.
Are there any patches to test or a plan for integration. Is it likely that it make it into stable until October? If so the next release will be really great for Composite.
I just updated the patches to incorporate some feedback last week; I hope to have them integrated for this release.
commit ec2fde7c8250fdc30984f16c8a1d3587d70b0144 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Jun 2 16:42:56 2009 +0100 Sync DRI2 CopyRegion to vertical retrace
(In reply to comment #9) > commit ec2fde7c8250fdc30984f16c8a1d3587d70b0144 > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > Date: Tue Jun 2 16:42:56 2009 +0100 > > Sync DRI2 CopyRegion to vertical retrace > This commit caused screen to stop redrawing. I use two monitors, laptop screen and external one. Works ok if I disconnect external monitor but it it's connected screen freezes.
(In reply to comment #10) > (In reply to comment #9) > > commit ec2fde7c8250fdc30984f16c8a1d3587d70b0144 > > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > > Date: Tue Jun 2 16:42:56 2009 +0100 > > > > Sync DRI2 CopyRegion to vertical retrace > > > > This commit caused screen to stop redrawing. I use two monitors, laptop screen > and external one. Works ok if I disconnect external monitor but it it's > connected screen freezes. Did you pull the updates after this commit? Eric fixed a few issues with this patch in a later commit... If things are still broken with master, please open a new bug.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > commit ec2fde7c8250fdc30984f16c8a1d3587d70b0144 > > > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > > > Date: Tue Jun 2 16:42:56 2009 +0100 > > > > > > Sync DRI2 CopyRegion to vertical retrace > > > > > > > This commit caused screen to stop redrawing. I use two monitors, laptop screen > > and external one. Works ok if I disconnect external monitor but it it's > > connected screen freezes. > > Did you pull the updates after this commit? Eric fixed a few issues with this > patch in a later commit... > > If things are still broken with master, please open a new bug. > I used version updated up to commit 4698b3bd79452ae2066a3d195cf58dd5e30c93f3, so with those fixes.
I've found out what causes the problem. As I said before I have 2 monitors and I use them in extended desktop configuration: xrandr --output VGA --right-of LVDS --auto. The problem is that my LVDS is 1680x1050 and VGA is 1920x1200. So what I get after xrandr is virtual screen 3600x1200. ______________________ | | | | S1 | S2 | | | | |_________| | |XXXXXXXXX|___________| if I instead did: xrandr --output VGA --right-of LVDS --mode 1680x1050 _____________________ | | | | S1 | S2 | | | | |_________|_________| everything works fine. So I believe the problem is when driver has to redraw area that is bigger then physical screen. Maybe then there is no MI_WAIT_FOR_PIPEB_SCAN_LINE_WINDOW for region which includes XXXXXXXX part (is partially below the screen).
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > commit ec2fde7c8250fdc30984f16c8a1d3587d70b0144 > > > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > > > Date: Tue Jun 2 16:42:56 2009 +0100 > > > > > > Sync DRI2 CopyRegion to vertical retrace > > > > > > > This commit caused screen to stop redrawing. I use two monitors, laptop screen > > and external one. Works ok if I disconnect external monitor but it it's > > connected screen freezes. > > Did you pull the updates after this commit? Eric fixed a few issues with this > patch in a later commit... > > If things are still broken with master, please open a new bug. > Opened bug 22203.
This is still an issue with -intel 2.8 and i915. It is much better than before but still tears often during tracking shots. So atm I have to disable KMS to use Overlay again.
(In reply to comment #15) > This is still an issue with -intel 2.8 and i915. It is much better than before > but still tears often during tracking shots. > So atm I have to disable KMS to use Overlay again. > Try using Option "SwapbuffersWait" "true" in xorg.conf
Yeah, the option >>Option "SwapbuffersWait" "true"<< seems to fix the problem for me. Many thanks!
The option "SwapbuffersWait" prevents the tearing of long lines but there are still from time to time fractals like short rectangles slower than the rest which makes watching a movie still kind of annoying some times. The main problem is that it isn't possible to use Overlay again with KMS.
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.