video tearing with textured video on intel card

[Ralph]

[Impact]
Previously we shipped an option to turn textured video on/off. For Intrepid, textured video was felt to be stable so we removed this option. However, as evidenced by this bug, some people are still seeing some issues, and wish to still have a mechanism to turn it on/off if they desire.

[Development Branch]
The identical fix is uploaded to Jaunty.

[Patch]
The attached patch is a modified version of one we've shipped for a long time in the past. It has been modified to default to on instead of off.

[Test Case]
On affected hardware, try setting the "TexturedVideo" option to false in xorg.conf. It will have no effect in the unpatched version. With the patched version, it will cause textured video to be disabled.

[Regression Potential]
Extremely unlikely. It just adds a configuration option whose default value leaves the system identical to how it was before.

For people who choose to use this option to turn off textured video, they may see artifacts, performance effects, or other undesired behavior (all reasons why textured video was desired to begin with). It is assumed that people who wish to configure their systems this way, will accept these behaviors.

[Original Report]
Textured video seems to be enabled in the intel driver now in intrepid and a patch that made it possible to disable it has been removed.

This leads to severe video tearing in all video players I tried: mplayer, totem, vlc.

The only workaround for me at the moment is to use mplayer and instruct it to use the xv port that isn't textured. This also seems to confirm, that it is indeed textured video that is causing the problem.

I'm using a netbook with a Mobile 945GME Express Integrated Graphics Controller.

My suggestion would be to give people who have this problem the opportunity back to disable textured video altogether.

[Arvind (arvind0)]

I have the same problem on an intel gma 965 (x3100)

[noOneSpecial (steve72b)]

Same here on an intel gma 950.

You can work around this problem in totem. If you run 'gstreamer-properties' from the terminal, select the video tab, and select 'X Window System (X11/XShm/Xv)' for the plugin option. You can select Overlay or Textured mode in the Device options. Textured mode gives be the tearing effect, Overlay seems to get rid of it. I assume this will work on all gstreamer based players.

[Arvind (arvind0)]

by running xvinfo i can get the port of video overlay
then using mplayer -vo xv:port={port} i can workaround this problem.

however this is quite unstable and causes the the display to go blank and the system freezes 20% of the time. The only thing i can do is switch off the power then

[Arvind (arvind0)]

I downgraded to the 2:2.4.0-1ubuntu1 version which was the version before the textured video was made default.
http://launchpadlibrarian.net/16642729/xserver-xorg-video-intel_2.4.0-1ubuntu1_i386.deb

video overlay is now the default(and only) rendering listed by xvinfo.

[Arvind (arvind0)]

update: Downgrading to the 2:2.4.0-1ubuntu1 version has not solved the problem. The computer freezes with the display becoming entirely blank/grey/green. A hard shutdown is necessary.

Also i notice that when i start any video, the screen flickers for an instant with random colours/lines before the video starts

[Bryce Harrington (bryce)]

Please attach the output of `lspci -vvnn`, and attach your
/var/log/Xorg.0.log file from after reproducing this issue.
If you've made any customizations to your /etc/X11/xorg.conf please
attach that as well.

[Arvind (arvind0)]

the screen changes to some random color, not just the ones listed above

[khelidan (khelidan)]

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

i have the same problems....intel developers says that in 2.5 release of driver tearing video troubles will be fix,but for now we need a patch to disable texured video!Again on Intrepid i have tering video also without compiz/composite

[Andreas Braml (a-strich-b)]

I can see this issue, too. Kubuntu Intrepid as of today, having KWin effects eabled or not doesn't make any difference. There's tearing in all players I use, even e.g. VLC under Wine.

[Ste (ilpillo)]

here we are, the tearing problem seems fixed in the new intel driver 2.5 release:
http://lists.freedesktop.org/archives/xorg/2008-October/039555.html

now we just need an updated package

[Andreas Braml (a-strich-b)]

Fixing the video tearing was planned for 2.5, but it wasn't. As says the announcement ipillo refers to ;)

[Arvind (arvind0)]

According to that post "(4) no more video tearing with textured video & XvMC" was planned but was missed out on this release. Was there something I missed?

[khelidan (khelidan)]

i thing is too late for an upgrade package in intrepid,i hope in a third part repo or i will try compile driver myself but i think it requires an update libdrm

[Ste (ilpillo)]

sorry for the mistake!
I have installed the new intel driver from here:
https://launchpad.net/~thjaeger/+archive
and the tearing bug is still there, by the way I have found a workaround to get a decent quality in movie playing, you just have to install driconf and enable the vsync option “always”
This trick works for me and fixes the tearing issue under mplayer (but not compiz)

[khelidan (khelidan)]

trick don't works for me,tearing is still here also with last 2.5 drivers and vsync

[Ste (ilpillo)]

I forgot to mention that you have to use the GL video driver in mplayer

[Øyvind Stegard (oyvindstegard)]

Tearing video in Intrepid here, too .. :(
HW: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)

* Using plain video-overlay XV-port works very poorly, but it doesn't crash Xorg. It is, however, not usable, and there are lots of artifacts, window rendering bugs, etc. whenever it is in use. But I'm guessing the plain old overlay works much better without Compiz (haven't tried, yet). However, in Hardy, using the plain overlay actually worked in Compiz, even though it wasn't properly composited, etc. I'd rather have that, than textured video with tearing.

* Using Textured Video XV-port (default) causes video-tearing, and that sucks. However, it plays very nicely together with Compiz.

* Enabling VSYNC in Compiz does not help.

[Øyvind Stegard (oyvindstegard)]

An update on my last comment:

Plain overlay actually works fine with MPlayer, and then there's no tearing :). Seems like only Totem has troubles with the plain overlay, probably b/c of different window/fullscreen handling.

[khelidan (khelidan)]

work for me thanks!
But do you know how set overlay port also in embedded adobe flash player?

[Tore Anderson (toreanderson)]

Status = Confirmed, happens here too. G33 chipset. Normal overlay works fine.

Tore

[Adam K (trogdor282)]

Same here. I had the same problem back in Hardy, and then Bryce put the patch in for overlay which fixed it, and there was much rejoicing, and now I think he took it back out again thinking the problem was fixed. It isn't.

[Nahuel (nawels)]

Same problem here after upgrading from Hardy.

HW: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

[Nahuel (nawels)]

Solved it in VLC changing the "XVideo adaptor number" to "1".

To do this go to Tools->Preferences, select "All" in "Show settings", then go to Video->Output modules->XVideo and change "XVideo adaptor number" value to "1". This will force VLC to use video overlay instead of textured.

[caish5 (caish5-hotmail)]

Same problem here with..

00:02.0 VGA compatible controller [0300]: Intel Corporation 82G35 Express Integrated Graphics Controller [8086:2982] (rev 03)

Such a disapointment because otherwise intrepid is very good.

[Bo90 (joakimcarli)]

Same problem as well with..

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

[Bo90 (joakimcarli)]

Can confirm that changing the "XVideo adaptor number" to "1" in VLC works!
Overlay works fine in VLC with compiz enabled.

[khelidan (khelidan)]

i use vlc and it works fine but i prefer a system wide solution,for example there is video tearing with flash video!
And totem doesn't work with compiz and overlay...

[Arvind (arvind0)]

even mplayer works with the setting vo=xv:port=83 (or whatever port you get
from xvinfo)
but flash tearing is one thing that is still very irritating

On Wed, Nov 5, 2008 at 3:12 AM, khelidan <email address hidden> wrote:

> i use vlc and it works fine but i prefer a system wide solution,for example
> there is video tearing with flash video!
> And totem doesn't work with compiz and overlay...
>
> --
> video tearing with textured video on intel card
> https://bugs.launchpad.net/bugs/278318
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Doc. Odine (doc-odine-cz)]

Same here, Intel 965.
The VLC solution does not work for me though.

[tghazali (tare2)]

Intel 945 here. Mplayer's workaround works great. I hope they release an update soon..

[Bryce Harrington (bryce)]

Adding an xorg.conf option to disable textured video in Intrepid is probably feasible. I can try taking a look at that.

[Tore Anderson (toreanderson)]

Bryce,

I think it would be better if your option simply re-ordered the textured video and overlay XVideo adapters, so that applications would use the overlay adapter by default.

Tore

[Timo Aaltonen (tjaalton)]

the patch is still there, just enable patch 11 and recompile the driver

Maybe the patch could be reworked to not use the overlay on 965, since textured video should work with it (does on mine, and for many others too).

[unggnu (unggnu)]

Can someone of the devs say something about the problem or at least give some very good reasons? This is serious.

I mean textured video output is standard in the intel driver for years and it still doesn't work because of the tearing or missing vsync.

Another thing I don't understand is why overlay can't be enabled with the VideoOverlay xorg.conf option anymore? Nearly all Intel graphic cards seem to support overlay so why mess it up for them too?

This all means that video output doesn't really work since ages and all distributions need patches.

I have an i915 card but according to https://bugs.launchpad.net/bugs/278318 many others are also effected.

[Aabones (aabones)]

From my understanding, and please correct me if I'm wrong, overlay hardware is obsoleted with the move to 3D hardware/software. So all the 2D operations that where implemented in the overlay now has to be re-implemented in 3D operations.

Also, this thread:
    http://<email address hidden>/msg04078.html
which mentions option A, a "trivial" solution that will cause everything else to perform worse, but might be acceptable for fullscreen video. I think the patch he refers to is the XvMC path mentioned above, which doesn't affect xv.

What is the possibility for getting that implemented and only enabling it via an xorg.conf variable? So those of us that only ever run in fullscreen video will be happy :)

[unggnu (unggnu)]

Atm video watching without seasickness is only possible with overlay output which requires a patched intel driver.
There might be penalties like blue borders with compiz or kwin but at least it works.
I guess nearly every standard user doesn't care if overlay is old, deprecated or 2d if there is no working alternative to watch videos.

If of course textured video uses vsync or similar and doesn't tear anymore I have no problem when overlay is disabled but this hasn't happened in over a year as I mentioned above.

Maybe if you have a time machine through which I could watch videos with a working intel driver textured video output it would be fine too. :D

Please remember that people live in the present, NOT in the future. Nobody needs textured video, EXA, UXA or any other new fancy feature if they mess things up. Workings features should be kept until the new ones are really able to replace them. That's why there normally is a stable and unstable branch.

[unggnu (unggnu)]

The Overlay option doesn't seem to work in Jaunty anymore and Intel driver has still the bug there so reopened.

[Arvind (arvind0)]

In jaunty I can specify xv overlay by using the option vo=xv:port=97 in
mplayer (97 was the port i got using xvinfo). However I still have the same
crashes with the entire screen turning a random colour and the system
hanging, like what happened in intrepid 20% of the time when i start a
video. So it is not a good enough solution/workaround. I am using Hardy now
since xv overlay works perfectly in it.

On Thu, Feb 19, 2009 at 6:12 PM, Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: xserver-xorg-video-intel
> Status: Unknown => Confirmed
>
> --
> video tearing with textured video on intel card
> https://bugs.launchpad.net/bugs/278318
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Will Uther (willu-mailinglists)]

One quick extra comment based on the "we're using 3D hardware now" meme: I tried using the opengl renderer in mythtv but it turned everything green and then froze. Once it froze I needed to reboot the machine to get my screen back - I couldn't restart X.

That is a separate bug, but it removes a possible work-around.

[Aabones (aabones)]

yes, I've been trying to use the opengl renderer in mythtv for sometime now, but it's always a green monochrome. It states this on the MythTV wiki under the XvMC section. http://www.mythtv.org/wiki/XvMC#Intel
Although I'm not using XvMC, just the opengl renderer, I'm still seeing the green.

I'm not sure what it is, intel driver or mythtv software. I can run mplayer using -vo GL or GL2 and it looks fine, and for a while had no tearing when using this. So I'm assuming its a mythtv colorspace conversion error. I haven't tested this in a while though.

http://svn.mythtv.org/trac/ticket/5999
No response.

[Andreas Braml (a-strich-b)]

The option in xorg.conf in Jaunty has been renamed to

Option "XvPreferOverlay" "true"

It's in the manpage. Works for me (TM), no freezes etc. that others report.

[unggnu (unggnu)]

OpenGL video output with EXA or UXA seem to have the tearing problem too. At least if used in kwin and with activated vsync option.

I don't know if this is a fglrx problem or a general OpenGL video one but the gl output seems to much more grainy than Xv. Not as much as Xorg video output but similar.

[Will Uther (willu-mailinglists)]

Started doing some debugging.

The mythtv vsync code is here: <http://svn.mythtv.org/trac/browser/trunk/mythtv/libs/libmythtv/vsync.cpp>.

If you edit the function drmWaitVBlank() on line 264 to include some calls to gettimeofday() and print out when the wait is less than 10ms, you'll see plenty of output.

If you look in the function DRMVideoSync::WaitForFrame() at line 325 you'll see some commented out debug statements. If you uncomment them you get:

WaitForFrame at : 15548 Delay at first sync: 7750
Wait 1 intervals. Count 60491126 Delay -8970
WaitForFrame at : 24978 Delay at first sync: 14499
Wait 1 intervals. Count 60491128 Delay -2240
WaitForFrame at : 46073 Delay at first sync: 37744
Wait 3 intervals. Count 60491132 Delay -12440
WaitForFrame at : 20562 Delay at first sync: 11037
Wait 1 intervals. Count 60491134 Delay -5689
WaitForFrame at : 28353 Delay at first sync: 17584
Wait 2 intervals. Count 60491137 Delay -15875
WaitForFrame at : 16296 Delay at first sync: 7597

The waitForFrame number is how long myth thinks you should wait from the time that function is called until the next frame should be displayed - i.e. how long it thinks it should sleep for. It then tries to sleep until the next vblank. It then calculates how long it has to sleep until it is near the next frame and shows that as the Delay number on the first line. i.e. the difference between those two numbers is how long the ioctl actually waited. Also note that the second number should be around 0 if myth was perfectly synced. This wont happen as there is 20ms between video frames and 16ms between vsyncs.

[Will Uther (willu-mailinglists)]

Having seen that it didn't want to sleep for more than 10ms, I added the following code at the front of myth's WaitForFrame():

    if (m_delay > 8000) {
      int sleepTime = m_delay - 6000;
      usleep(sleepTime);
    }

i.e. delay until there are 2ms until the time myth thinks the frame should be displayed. This leads to logs that look like this:

WaitForFrame at : 17808 sleeptime : 11808
WaitForFrame II at : 5870 Delay at sync: -9631
WaitForFrame at : 24409 sleeptime : 18409
WaitForFrame II at : 5865 Delay at sync: -2885
WaitForFrame at : 31029 sleeptime : 25029
WaitForFrame II at : 5871 Delay at sync: 3662
Wait 1 intervals. Count 93245119 Delay -13069
WaitForFrame at : 21271 sleeptime : 15271
WaitForFrame II at : 5849 Delay at sync: -6322

And the problem wasn't fixed.

[Michel Dänzer (michel-daenzer)]

Please take the MythTV issue elsehwere, as it isn't directly related to this bug. The DRM vblank support isn't intended to be used by applications directly.

[unggnu (unggnu)]

Works for me, even with UXA.

Thanks.

[Arvind (arvind0)]

I think the fix might be card dependent. Does the fix work for anyone with a
GM965 (X3100) card?

On Fri, Feb 20, 2009 at 4:56 AM, Andreas Braml <email address hidden> wrote:

> The option in xorg.conf in Jaunty has been renamed to
>
> Option "XvPreferOverlay" "true"
>
> It's in the manpage. Works for me (TM), no freezes etc. that others
> report.
>
> --
> video tearing with textured video on intel card
> https://bugs.launchpad.net/bugs/278318
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[unggnu (unggnu)]

I965 should still support overlay if the intel devs haven't removed the code too but I can't test it.

[Will Uther (willu-mailinglists)]

  You're saying this is a Mythtv bug? Mythtv didn't tear with my previous graphics card (admittedly a couple of things have changed as well as the graphics card - narrowing that down is what debugging is about).

  What is the correct way to get video sync? (i.e. If I take this tearing to the mythtv mailing list, I'll need to tell them more than "I get tearing". I'd really like to be able to say something like "I get tearing because mythtv does its vsync wrong - according to the intel driver guys it shouldn't be doing X, it should be doing Y".)

  Is there another program that you know does it 'right' and hence would allow me to test my setup?

[unggnu (unggnu)]

@ William Uther
Just use overlay if possible. I guess most distributions have patches for it, at least Ubuntu.

According to this mailing list entry http://<email address hidden>/msg04078.html posted before the Intel devs are fully aware that textured video does tear and it looks like that it does on every Intel card. They were planning to fix this with DRI2 but the changes doesn't make it in time.
Furthermore it was no problem for them to disable and remove the non tearing output - overlay - a year ago or something like that.

I guess either Intel devs doesn't watch videos with their pcs, have another graphic card, always use patched drivers or live in the future/have a time machine :D .

I mean if this situation appears for some weeks or a month, nobody would care but you wouldn't salvage your only car if your new one arrives in over a year.

Maybe it is only me but I don't get it.

[Sven Arvidsson (sa)]

By the way, is it only possible for a gl-based compositing manager (such as compiz) to use sync to vblank to get rid of tearing, or would it also be possible for an xrender based one (such as metacity)?

[Jesse Barnes (jbarnes-virtuousgeek)]

If X has an equivalent of glXSwapBuffers, and we can make it swap w/o tearing, then yes. But at this point that's not possible. And in fact even with a GL compositor it's not possible in a reliable way on Intel; we don't implement a reliable buffer swap, and waiting for vblank in the client is subject to scheduling hiccups, so isn't really suitable.

[Aabones (aabones)]

Does this thread solve this bug? I'm getting good results:

http://lists.freedesktop.org/archives/intel-gfx/2009-March/001608.html

>>>
I finally get to report some good news...great news in fact. I finally have
tear free XV fullscreen video on my G45. No Compiz needed, w00t! Thanks to
all the devs/community for getting it there.

I just sync'd to head on xf86-video-intel driver. This is what else I'm
running, all -9999 packages were sync'd to head within the last week of this
posting.

media-libs/mesa-9999
x11-libs/libX11-9999
x11-libs/libXext-9999
x11-libs/libXi-9999 (XInput.h moved to)
x11-libs/libdrm-9999
x11-libs/libxcb-9999
x11-proto/dri2proto-9999
x11-proto/inputproto-9999 (XInput.h moved from)
x11-proto/xcb-proto-9999
x11-proto/xextproto-9999
x11-proto/xproto-9999
x11-drivers/xf86-input-evdev-2.1.3
x11-drivers/xf86-input-keyboard-1.3.2
x11-drivers/xf86-input-mouse-1.4.0
x11-drivers/xf86-video-intel-9999
x11-base/xorg-server-1.6.0
x11-wm/openbox-3.4.7.2
kernel intel-drm 2.6.28 (w/ patches)
gentoo ~amd64

Runs mythfrontend, openbox, and X, within 1gig of ram. Fullscreen video with
EXA was tear-free at 1080p and 720p, E8400 cpu ~20-27%

[Haihao-xiang (haihao-xiang)]

fixed in xf86-video-intel
commit 67fef27f4b76490be085d232aba0ca9cbb3c5e59
Author: Xiang, Haihao <email address hidden>
Date: Fri Mar 6 09:40:07 2009 +0800

    Xv: free tearing on textured video

    Add an Xv attribute XV_SYNC_TO_VBLANK which has three values -1(auto), 0(off)
    and 1(on) to control whether textured adapter synchronizes the screen
    update to the vblank. The default value is -1(auto).

[Sven Arvidsson (sa)]

The description in the man page is a bit confusing:

 It has three
 values 'auto'(-1), 'off'(0) and 'auto'(1). 'off' means never sync, 'on' means
 always sync, no matter what size, and 'auto' means sync if the Xv image is
 more than quarter of the pixels on the screen. The default is 'auto'(-1).

I guess it should say 'on'(1)?

As for tearing, it doesn't seem to be fixed on my G45.

The default value of XV_SYNC_TO_VBLANK seems to be 1. Even if I manually set -1 or 0, it's set back to 1 after using MPlayer.

[Haihao-xiang (haihao-xiang)]

(In reply to comment #32)
> The description in the man page is a bit confusing:
>
> It has three
> values 'auto'(-1), 'off'(0) and 'auto'(1). 'off' means never sync, 'on' means
> always sync, no matter what size, and 'auto' means sync if the Xv image is
> more than quarter of the pixels on the screen. The default is 'auto'(-1).
>
> I guess it should say 'on'(1)?
It should be 'on' (1).

> As for tearing, it doesn't seem to be fixed on my G45.
Really? I tested on my GM965/GM45/G45 and don't see tearing any more. Comment #30 also said he got good result on his G45.

> The default value of XV_SYNC_TO_VBLANK seems to be 1. Even if I manually set -1
> or 0, it's set back to 1 after using MPlayer.
The default valude is -1, you can use xvattr to query it before using MPlayer. It is changed by MPlayer. (some other video drivers also have XV_SYNC_TO_VBLANK attribute, and MPlayer sets it to sync by default)

>

[Sven Arvidsson (sa)]

(In reply to comment #33)
> Really? I tested on my GM965/GM45/G45 and don't see tearing any more. Comment
> #30 also said he got good result on his G45.

Yeah, it's weird, tearing seems worse now. There's almost always a horizontal tear in any full-screen video.

[Sven Arvidsson (sa)]

I figured out why. It's because of the Xrender based compositor Metacity uses.

It is limited to 50 fps at the moment, I have tried to increase the refresh rate, but so far I haven't noticed a difference.

It seems to work fine if the compositor is turned off, so I guess this problem lies with metacity?

[Haihao-xiang (haihao-xiang)]

Jesse has some commits to eliminate tearing when using composite manager, but he doesn't push them out now.

[caish5 (caish5-hotmail)]

I've so far managed to get Kaffeine and Miro to play nice by adding the tweaks to xorg.conf.
However Totem is still tearing.
Is there specific settings that fix it in gstreamer-properties that i don't know about?

[unggnu (unggnu)]

Is this supposed to be fixed in intel 2.6.3?
It is not so I think this bug shouldn't be marked as resolved.

[Jesse Barnes (jbarnes-virtuousgeek)]

(In reply to comment #37)
> Is this supposed to be fixed in intel 2.6.3?
> It is not so I think this bug shouldn't be marked as resolved.

We already have https://bugs.freedesktop.org/show_bug.cgi?id=20664 open for the composite tearing case. Our driver doesn't yet support a good method to prevent tearing of OpenGL or composited applications, but I have some patches to add that. I'll point people at them in #20664.

[Will Uther (willu-mailinglists)]

Just so that I understand unggnu's comment correctly... This bug isn't fixed in 2.6.3, but is fixed in the repository and that fix will be released in 2.7, right?

[Cype (mikards)]

I have this same problem with Intrepid. Video tearing with intel i945 chipset laptop. I have tried almost everything and now run out of ideas.

This mplayer command works fine mplayer -vo xv:port=98 (98 is the overlay port) but I'd like to get it working with VLC and other programs too. Will insert xorg.conf and xorg.0.log soon.

[Dekar (dekar-wc3edit)]

I think this bug should be reopened until the default configuration is tearing free!

[pvanbrakel (pvanbrakel-deactivatedaccount)]

Have the same problem with the video tearing while playing a dvd with or without compiz turned on, so also with the gtk metacity manager, the dvd shows big lines. All the other movie files are fine, except dvd. I tried this whole week all the solutions, but none of them seems to help.

Iam using ubuntu 9.04:

Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

though after testing, kaffeine seems to have less trouble playing dvds

pieter

[Anton Blanchard (anton-samba)]

The G45 chips only support textured video so the workaround is no good for them. The issue is fixed in the upstream driver:

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=67fef27f4b76490be085d232aba0ca9cbb3c5e59

I built from the 2.7 branch and the tearing went away. It would be great if someone could make a PPA of it.

[unggnu (unggnu)]

It is only fixed if composite isn't enabled but according to the devs this should be fixed soon.

Btw. there is already a ppa with stable upstream drivers https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates/ .

[Andy (acc-launchpad)]

Can confirm that adding

Section "Extensions"
    Option "Composite" "false"
EndSection

and using x-updates ppa the tearing is gone on the textured video port.

00:02.0 VGA compatible controller: Intel Corporation 82G35 Express Integrated Graphics Controller (rev 03)

[pvanbrakel (pvanbrakel-deactivatedaccount)]

Dear Andy,

I tried these solution, and the video tearing almost disapeared, except by fast actions, it still shows some tearing. parts of a movie with simple camp fire for example.

pieter

[Arvind (arvind0)]

Video tearing with composite seems to have been solved upstream.

https://bugs.freedesktop.org/show_bug.cgi?id=20664

With the latest drivers from the xorg-edgers ppa there doesn't seem to be any tearing. Although, it did cause some system hangs on screen blanking using dpms/screensaver.

[unggnu (unggnu)]

This is still an issue in Karmic. It is better than before but still makes video watching impossible with my i915.
Since KMS it is not possible to activate Overlay output so I need to disable this too.

[Denis Malinovsky (dmalinovsky)]

Recently I often bought some products from a business company.
Very cost-effective and convenient,
if you are free, you can go to browse: okayele.com ,
enrich a shopping choice for yourself wonderful life