I should probably clarify that when I say it "stopped syncing properly", that it hasn't stopped syncing completely. I can see that the driver is limiting Xv frames to the refresh rate, but it still manages to miss the blanking period. The tear is frequent, and all over the place.

I have experimented with making a test application but have so far been unable to provoke the issue outside of mplayer.

After some debugging and discussion on #nouveau, it was determined that this is caused by mplayer creating its windows with backing store enabled. The newer Xorg in F9 makes these windows end up off screen, which makes nouveau ignore syncing (rightfully so).

So the question is how/why this worked in the Xorg in F8 and if that behaviour can be moved over to the new server. It might also simply be that mplayer shouldn't be requesting backing store.

Btw, the log says that backing store is disabled which I'd expect to give the effect that windows are always created without it.

One solution is also to make sure things are vsync:ed when they are transferred on screen by the X server. I did a quick hack in NVExaCopy() that solved the issue:

	if (NVExaPixmapIsOnscreen(pDstPixmap)) {
		uint8_t crtcs = nv_window_belongs_to_crtc(pScrn, dstX, dstY, width, height);

		FIRE_RING();
		if (crtcs & 0x1)
			NVWaitVSync(pScrn, 0);
		else if (crtcs & 0x2)
			NVWaitVSync(pScrn, 1);
	}

It slows down a whole bunch of operations though, so it would need to be a bit more clever.

For reference, here's the diff that causes this:

http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blobdiff;h=c557eebc4de017e2bd266b7fe0bb9e5d1c791038;hp=630f1042c103cc1e7525f621cce9c84367774c3c;hb=ae7f71a8b3d6756161e55d998d6eec37d2695c98;f=composite/compinit.c

It causes an implicit redirect whenever backing store is enabled. So one "solution" is simply to disable the composite extension.

NVWaitVSync stalls everything, this is not useful for generic rendering. Better
solutions involve a lot more effort (and i'm certainly not the one to judge
what is the right way). The problem you want solved is a lot larger then you might think.

The problem I want solved is to get mplayer to start working with vsync again. That doesn't have to mean that backing store gets vsync behaviour. Altough turning of composite works for my use case, it's probably not a good long term solution.

I'm adding ajax as a cc here as he was the one that reimplemented the backing store.

How did the backing store work before the rewrite? Did it track the damage of the framebuffer and had a backup copy? If so, was the change of behaviour in the new version fully realised?

If the easiest route is to get applications to change, then some arguments are needed why this isn't a bug/regression in Xorg, but applications relying on something they were never supposed to have.

(In reply to comment #6)
> The problem I want solved is to get mplayer to start working with vsync again.
> That doesn't have to mean that backing store gets vsync behaviour. Altough
> turning of composite works for my use case, it's probably not a good long term
> solution.
> 
> I'm adding ajax as a cc here as he was the one that reimplemented the backing
> store.
> 
> How did the backing store work before the rewrite? Did it track the damage of
> the framebuffer and had a backup copy? If so, was the change of behaviour in
> the new version fully realised?
> 
> If the easiest route is to get applications to change, then some arguments are
> needed why this isn't a bug/regression in Xorg, but applications relying on
> something they were never supposed to have.

I'm completely at a loss to understand why a) mplayer needs backing store at all, b) how it manages to interact with vsync.  It's not like you ever had control over when drawing happened in X relative to vsync...

(In reply to comment #7)
> (In reply to comment #6)
> > The problem I want solved is to get mplayer to start working with vsync again.
> > That doesn't have to mean that backing store gets vsync behaviour. Altough
> > turning of composite works for my use case, it's probably not a good long term
> > solution.
> > 
> > I'm adding ajax as a cc here as he was the one that reimplemented the backing
> > store.
> > 
> > How did the backing store work before the rewrite? Did it track the damage of
> > the framebuffer and had a backup copy? If so, was the change of behaviour in
> > the new version fully realised?
> > 
> > If the easiest route is to get applications to change, then some arguments are
> > needed why this isn't a bug/regression in Xorg, but applications relying on
> > something they were never supposed to have.
> 
> I'm completely at a loss to understand why a) mplayer needs backing store at
> all, b) how it manages to interact with vsync.  It's not like you ever had
> control over when drawing happened in X relative to vsync...
> 

As a special case, when composite isn't used, we stall the rendering engine so xvideo looks good. This was a quick way to get reasonable results.

(In reply to comment #7)
> 
> I'm completely at a loss to understand why a) mplayer needs backing store at
> all, b) how it manages to interact with vsync.  It's not like you ever had
> control over when drawing happened in X relative to vsync...
> 

a) If I'd guess, I'd say it was a quick way to avoid having to deal with keeping the color key updated, and it has worked just fine up til now.

b) As Maarten said, the rendering (specifically, the PutImage operations) is stalled until vsync blanking, but only if the target Xv window is on screen. The new backing store code moved the window off screen.

I have nv20, and both the overlay and blitter work the same: I have a static horizontal tearing line, location depending on window size.

Section "Extensions"
        Option "Composite" "off"
EndSection

With Composite disabled with the above config, blitter now works fine. Overlay on the other hand does not, video appears jerky and there is occasional tearing at random places. I'll file a separate bug report on this.

I do not have a texture adapter. Xorg-server is from git.

I've posted a comment to the mplayer-users list.
http://article.gmane.org/gmane.comp.video.mplayer.user/57029

I also cannot use the overlay any longer with git xorg (nv34 on powerpc, but I do not experience the overlay problem without composite as in the last comment, this seems to be a separate bug).

I agree that this problem is probably in mplayer, but there is however at least one bug in X here: it says in the log that the backingstore is disabled, but it is not. And all disabling it at commandline or in xorg.conf does not have any effect.

d.

Mplayer has been fixed to not use backing store.