Created attachment 38044 [details] [review] Patch against 2.6.35.3 to remove the offending code Since upgrading from 2.6.34, programs such as Neverball and MythTV have only updated the screen while moving the mouse or pressing keys. I managed to bisect the kernel back to the infamous commit bc35afdb182d4c48c889fe27ba7a5d7ea0c8194d, along with its related fix 0baf2d8fe43fdd81faa30e65ff71785c99c78520. These add support for querying the hardware CRTC ID. I knew straight away that this was probably related to me using Zaphod mode and a test with a single screen did indeed make the problem go away. There was still the occasional flicker though, which may or may not be related. I don't get any flickering with the code removed (see attached patch) while using Zaphod mode. I knew it was probably related to Zaphod mode because I know that the CRTCs play a key role there but beyond that, I'm not sure what the problem is. I don't know exactly what this code is used for. I probably should have tested two screens without Zaphod mode but my wife will kill me if I restart the machine again. ;) I'm guessing that isn't affected because it's a very common setup.
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. ***
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.