Bug 29726

I should add that, despite the similarities, this doesn't seem to be the same as bug #29327. Booting with pci=nomsi makes no difference for me.

Just a note to say that this is NOT fixed as of linux-next-20100827.

I have now tested with two monitors, once in "clone" mode and once in "big desktop" mode and the behaviour is the same as with a single monitor. Just the occasional flicker. This is definitely related to Zaphod mode.

The problem still present on linux-next-20100917. Please guys, at least explain the context surrounding this code and where it would be called from. I've seen some other odd behaviour that could potentially be related to this and it's really starting to bug me.

*** Bug 31066 has been marked as a duplicate of this bug. ***

vblank synchronization apparently does not work correctly in zaphod mode.  You can disable it by setting the env var vblank_mode=0.

I was thinking you actually meant the .drirc setting rather than an actual environment variable but you were right. Setting this in .drirc makes no difference but the environment variable does indeed make the problem go away.

I quite like vsyncing so I'm a little sad if it's broken. I think it was working before?

(In reply to comment #6)
> I was thinking you actually meant the .drirc setting rather than an actual
> environment variable but you were right. Setting this in .drirc makes no
> difference but the environment variable does indeed make the problem go away.
> 

It's works in the .drirc as well, but it requires slightly different handling for dri2 drivers, e.g.,

<driconf>
    <device screen="0" driver="dri2">
        <application name="Default">
            <option name="vblank_mode" value="0" />
        </application>
    </device>
</driconf>

> I quite like vsyncing so I'm a little sad if it's broken. I think it was
> working before?

It wasn't supported before.  KMS vsync support was added with the commit cited in this bug.

(In reply to comment #7)
> > I quite like vsyncing so I'm a little sad if it's broken. I think it was
> > working before?
> 
> It wasn't supported before.  KMS vsync support was added with the commit cited
> in this bug.

It's been so long since I had a driver with working vsync that I've forgotten what it looks like. ;)

should be fixed on master DDX now.

(In reply to comment #9)
> should be fixed on master DDX now.

Thank you so much for your commit. The vsync of the proprietary driver was broken in the second display in new Ubuntu, so I switched to the free driver, to find it much better than when I last saw it. No way I would go back to fglrx, but I still could not use the second display (my TV) the way I was used to (to watch movies, separated displays/screens, vsync on) because of this bug... I was using big desktop mode until now!

I just tested the driver with the fix, and vsync seemed to work in zaphod mode, in both screens. DISPLAY=:0.0 is my monitor with 1280x1024 at 60Hz and DISPLAY=:0.1 is my TV with 1920x1080, also at 60Hz. I played a movie with mplayer in both screens (gl backend, vsync on) and I could see no visible tear that was obvious when vsync was off. glxgears is also limited at 60 FPS, as it should be.

Now I am not sure how to test it without relying on my eye and a movie (I am satisfied with the result). My test may be unreliable, since I was not able to shut off vsync in mplayer in a way that I could see the tears I was used to see with vsync=off in fglrx. Env var vblank_mode=0 shows no artifacts, neither when running mplayer nor glxgears, although its FPS is not limited at 60 anymore.

(In reply to comment #9)
> should be fixed on master DDX now.

I patched against 6.13.2 and it works great now. Thanks, Dave. :)

*** Bug 32885 has been marked as a duplicate of this bug. ***