[ANNOUNCE] xf86-video-intel 2.6.99.903

[Carl Worth]

On Wed, 2009-04-15 at 09:29 +0100, Jonathan Miles wrote:
> On 15/04/09 09:08 Tino Keitel said the following:
> 
> > What is required for tearing-free xv? I have XV_SYNC_TO_VBLANK set to 1
> > on all XV ports, but still see tearing on i945. I don't have KMS enabled.
> 
> Me too. I was going to send an e-mail about it later, but since you've 
> brought it up... I don't know enough about the relationships between the 
> graphics systems to tell whether this is a configuration issue or a bug.

There's not supposed to be anything else required for tear-free XV. So
something is going wrong. You might be happy (or not) to know that
you're not the first to hit this bug. See the report here where we're
trying to diagnose this problem:

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

I haven't been able to replicate this problem myself, (I get tear-free
XV on both a 945GM and a GM965).

> * Kernel 2.6.29 + KMS. Horizontal tears are constantly in the same two 
> places on screen, as if it's synced but incorrectly. Note that with this 
> config, I had to use xrandr to create and set a +vsync mode as DDC 
> output in Xorg log shows all modes with -vsync.

Behavior with tearing in the same place consistently is very odd. And
that almost suggests to me that something other than our driver code in
i830_video.c is trying to sync. (Do you a compositing manager running
perhaps?) The reason I say that is that in 2.6.99.902 and earlier, our
driver was syncing to vertical retrace for tear-free video. But, to fix
a bug, (GPU hang when screensaver activated during XV syncing), I
changed the driver to not sync on vertical retrace. Instead we get
tear-free video now by waiting only until the refresh is outside the
current window. So I wouldn't expect that code to ever give you any
consistent tearing.

But then again, maybe nothing is syncing, (see my latest comment in the
bug suggesting the driver might be trying to sync on pipe B while a
video is being displayed on pipe A), and there's some unrelated change
that results in the tearing being in a consistent location.

-Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20090415/793441c3/attachment.pgp>