Bug 29726 - New CRTC ID query breaks Radeon DRM in Zaphod mode
Summary: New CRTC ID query breaks Radeon DRM in Zaphod mode
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
: 31066 32885 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-21 08:36 UTC by James Le Cuirot
Modified: 2011-01-06 15:54 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch against 2.6.35.3 to remove the offending code (1.31 KB, patch)
2010-08-21 08:36 UTC, James Le Cuirot
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot 2010-08-21 08:36:53 UTC
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.
Comment 1 James Le Cuirot 2010-08-21 08:45:31 UTC
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.
Comment 2 James Le Cuirot 2010-08-28 07:42:15 UTC
Just a note to say that this is NOT fixed as of linux-next-20100827.
Comment 3 James Le Cuirot 2010-09-18 16:21:02 UTC
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.
Comment 4 Alex Deucher 2010-10-24 08:31:13 UTC
*** Bug 31066 has been marked as a duplicate of this bug. ***
Comment 5 Alex Deucher 2010-10-24 08:33:15 UTC
vblank synchronization apparently does not work correctly in zaphod mode.  You can disable it by setting the env var vblank_mode=0.
Comment 6 James Le Cuirot 2010-10-24 16:03:20 UTC
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?
Comment 7 Alex Deucher 2010-10-24 22:09:03 UTC
(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.
Comment 8 James Le Cuirot 2010-10-25 02:11:15 UTC
(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. ;)
Comment 9 Dave Airlie 2010-10-27 18:13:16 UTC
should be fixed on master DDX now.
Comment 10 Lucas 2010-10-27 19:48:00 UTC
(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.
Comment 11 James Le Cuirot 2010-10-28 03:25:08 UTC
(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. :)
Comment 12 Alex Deucher 2011-01-06 15:54:13 UTC
*** 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.