Bug 39696 - dual head: different vert refresh freq, applications sync to the wrong one
Summary: dual head: different vert refresh freq, applications sync to the wrong one
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-30 10:02 UTC by Klaus Kusche
Modified: 2011-08-10 09:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.log having the problem (39.18 KB, text/plain)
2011-08-09 05:29 UTC, Klaus Kusche
no flags Details
All other things being equal, sync to the CRTC of the primary output. (1.58 KB, patch)
2011-08-09 10:20 UTC, Michel Dänzer
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kusche 2011-07-30 10:02:40 UTC
I've a notebook with a JUNIPER 0x1002:0x68A0 chip, using KMS, dri and gallium.

I mostly use external monitors connected by display port, HDMI or DVI,
cloning the internal display onto them (identical resolution, identical screen).

No matter what monitor (I tried two different Dell, an Iiyama and an Acer) and 
what port (DVI, HDMI, DP) I use, 
KMS always sets sligthly different vertical refresh frequencies: 
The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.

However, although I only look at the external monitor, all applications
(both 3D/DRM and video/Xv) sync to the vert refresh of the internal display.

This results in very nasty tearing effects: 
A clearly visible horizontal offset line moves up slowly on the external monitor 
for any video or 3D application (cyclically with a period of about 10 seconds).

1.) Is there a way to run both displays at exactly the same vert frequency
and with synchronized vertical retrace?
2.) Is there a way to switch 3D and video application sync
from the internal to the external vsync rate?
Comment 1 Michel Dänzer 2011-08-09 03:54:57 UTC
(In reply to comment #1)
> KMS always sets sligthly different vertical refresh frequencies: 
> The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.

Please attach the Xorg.0.log file, but most likely the external monitor's timing is what it specifies as preferred in its EDID.


> However, although I only look at the external monitor,

Then you could switch off the internal display?


> 1.) Is there a way to run both displays at exactly the same vert frequency

You could try manually setting the internal display's mode on the external monitor (or the other way around, but internal panels are typically pickier).

> and with synchronized vertical retrace?

There's no mechanism for that yet in general. However, if you manage to use the same mode for both displays, you might be able to source both of them off the same CRTC, in which case they should be perfectly synchronized.

> 2.) Is there a way to switch 3D and video application sync
> from the internal to the external vsync rate?

For video, you can use the XV_CRTC attribute to choose which CRTC to sync to (see the radeon manpage).

There's no such mechanism for 3D yet.
Comment 2 Klaus Kusche 2011-08-09 05:29:04 UTC
Created attachment 50068 [details]
Xorg.log having the problem

Xorg.log with one of the displays having the problem
(similar problem with another display and also external beamer).
Comment 3 Klaus Kusche 2011-08-09 05:47:04 UTC
(In reply to comment #1)
> (In reply to comment #1)
> > KMS always sets sligthly different vertical refresh frequencies: 
> > The internal display runs at 60 Hz, the external monitor runs at 59.9 Hz.
> 
> Please attach the Xorg.0.log file, but most likely the external monitor's
> timing is what it specifies as preferred in its EDID.

Attached.
Yes, EDID modes used for both outputs.

> > However, although I only look at the external monitor,
> 
> Then you could switch off the internal display?

Tried that. Works (tearing gone, obviously now syncs to ext monitor).
Could be done when I'm working at my desk,
but is impractical when using a beamer in class 
(in this case, I need the internal display).

> > 1.) Is there a way to run both displays at exactly the same vert frequency
> 
> You could try manually setting the internal display's mode on the external
> monitor (or the other way around, but internal panels are typically pickier).

To my surprise, this *doesn't* work:
I defined a new mode (tried both the external and internal modeline) in xrandr,
assigned it to both outputs, switched both outputs to the new mode
(both LVDS and ext display seem to accept both modelines),
but the tearing is still there.
The sync offset line now moves at a different speed and direction,
but is still clearly visible.

Either the actual settings are not what xrandr believes,
or the base clocks of the CRTC's are different.

By the way, is there an easy way to "take mode 1920x1200" from output X
and assign it to output Y" in xrandr? Or do I have to manually define
a new modeline by cut & paste from Xorg.log and assign it to both?

> > and with synchronized vertical retrace?
> 
> There's no mechanism for that yet in general. However, if you manage to use the
> same mode for both displays, you might be able to source both of them off the
> same CRTC, in which case they should be perfectly synchronized.

Can this be set using xrandr or something else?

> > 2.) Is there a way to switch 3D and video application sync
> > from the internal to the external vsync rate?
> 
> For video, you can use the XV_CRTC attribute to choose which CRTC to sync to
> (see the radeon manpage).

Works using xvattr: The sync offset line is now moving on the internal display.

> There's no such mechanism for 3D yet.

From the user's point of view, xvattr would be expected to set both?
Comment 4 Michel Dänzer 2011-08-09 06:39:31 UTC
(In reply to comment #3)
> > > and with synchronized vertical retrace?
> > 
> > There's no mechanism for that yet in general. However, if you manage to use the
> > same mode for both displays, you might be able to source both of them off the
> > same CRTC, in which case they should be perfectly synchronized.
> 
> Can this be set using xrandr or something else?

Yeah, using the --crtc option. With xrandr --verbose you can see which CRTCs an output can use.


> > > 2.) Is there a way to switch 3D and video application sync
> > > from the internal to the external vsync rate?
> > 
> > There's no such mechanism for 3D yet.
> 
> From the user's point of view, xvattr would be expected to set both?

Not sure how xvattr could be expected to affect anything but XVideo.

Some random ideas: All other things being equal, the driver could synchronize to the CRTC of the primary output, which can be changed using xrandr --primary. Or if that's not good enough, we could add special RandR properties for this.
Comment 5 Klaus Kusche 2011-08-09 07:28:24 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > > > and with synchronized vertical retrace?
> > > 
> > > There's no mechanism for that yet in general. However, if you manage to use the
> > > same mode for both displays, you might be able to source both of them off the
> > > same CRTC, in which case they should be perfectly synchronized.
> > 
> > Can this be set using xrandr or something else?
> 
> Yeah, using the --crtc option. With xrandr --verbose you can see which CRTCs an
> output can use.

Doesn't work the way we would like it:
* All outputs can be connected to all CRTC's.
* Default is LVDS:0, DP: 1
* Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0 using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but running both from the same CRTC seems to be impossible.

However, according to xrandr -- verbose they are not clones. 
How do I set them to clone mode?

> > > > 2.) Is there a way to switch 3D and video application sync
> > > > from the internal to the external vsync rate?
> > > 
> > > There's no such mechanism for 3D yet.
> > 
> > From the user's point of view, xvattr would be expected to set both?
> 
> Not sure how xvattr could be expected to affect anything but XVideo.

I didn't mean that I expect xvattr to do that,
I just wanted to say that the average user would expect that a single setting
controls both.

> Some random ideas: All other things being equal, the driver could synchronize
> to the CRTC of the primary output, which can be changed using xrandr --primary.
> Or if that's not good enough, we could add special RandR properties for this.

Currently both Xv and GL sync to LVDS by default,
no matter which output is primary,
and no matter which CRTC they use: 
Even if DP is primary and CRTC 0, sync is on LVDS.
Comment 6 Alex Deucher 2011-08-09 08:56:34 UTC
(In reply to comment #5)
> 
> Doesn't work the way we would like it:
> * All outputs can be connected to all CRTC's.
> * Default is LVDS:0, DP: 1
> * Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0
> using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
> reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but
> running both from the same CRTC seems to be impossible.
> 
> However, according to xrandr -- verbose they are not clones. 
> How do I set them to clone mode?

We disable cloning of certain encoders in the driver.  At the hardware level, you can source multiple encoders to the same crtc, but there are too many encoder specific limitations in most cases that make it hard to support cloning from the same crtc.  DP and LVDS are not possible for example as they use different clocking for the encoders.  LVDS is direct clocked from the PPLL while DP uses fixed clock derived from the DCPLL, so you can't drive both off the same crtc easily, at least not the way the driver is currently structured.

> 
> Currently both Xv and GL sync to LVDS by default,
> no matter which output is primary,
> and no matter which CRTC they use: 
> Even if DP is primary and CRTC 0, sync is on LVDS.

You might try assigning primary flag to the DP output.
xrandr --output DisplayPort-0 --primary
Comment 7 Klaus Kusche 2011-08-09 09:07:03 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > 
> > Doesn't work the way we would like it:
> > * All outputs can be connected to all CRTC's.
> > * Default is LVDS:0, DP: 1
> > * Even if the mode is exactly the same: As soon as I connect the DP to CRTC 0
> > using xrandr, xrandr automatically reconnects LVDS to CRTC 1 (and if I
> > reconnect the LVDS, DP is also switched). Hence, they can exchange CRTC's, but
> > running both from the same CRTC seems to be impossible.
> > 
> > However, according to xrandr -- verbose they are not clones. 
> > How do I set them to clone mode?
> 
> We disable cloning of certain encoders in the driver.  At the hardware level,
> you can source multiple encoders to the same crtc, but there are too many
> encoder specific limitations in most cases that make it hard to support cloning
> from the same crtc.  DP and LVDS are not possible for example as they use
> different clocking for the encoders.  LVDS is direct clocked from the PPLL
> while DP uses fixed clock derived from the DCPLL, so you can't drive both off
> the same crtc easily, at least not the way the driver is currently structured.

That would also explain why I still have a moving tear line even when using
exactly the same modeline on both - their base clock seems to differ slightly.

> > Currently both Xv and GL sync to LVDS by default,
> > no matter which output is primary,
> > and no matter which CRTC they use: 
> > Even if DP is primary and CRTC 0, sync is on LVDS.
> 
> You might try assigning primary flag to the DP output.
> xrandr --output DisplayPort-0 --primary

That's what I tried, but both GL and Xv still sync to LVDS?
Comment 8 Michel Dänzer 2011-08-09 09:13:15 UTC
(In reply to comment #7)
> > > Currently both Xv and GL sync to LVDS by default,
> > > no matter which output is primary,
> > > and no matter which CRTC they use: 
> > > Even if DP is primary and CRTC 0, sync is on LVDS.
> > 
> > You might try assigning primary flag to the DP output.
> > xrandr --output DisplayPort-0 --primary
> 
> That's what I tried, but both GL and Xv still sync to LVDS?

I was merely describing an idea for how we could make this work, not how it's currently working...
Comment 9 Michel Dänzer 2011-08-09 10:20:35 UTC
Created attachment 50076 [details] [review]
All other things being equal, sync to the CRTC of the  primary output.

Does this patch work for making 3D and video synchronize to the primary output by default?
Comment 10 Klaus Kusche 2011-08-09 12:17:56 UTC
(In reply to comment #9)
> Created an attachment (id=50076) [details]
> All other things being equal, sync to the CRTC of the  primary output.
> 
> Does this patch work for making 3D and video synchronize to the primary output
> by default?

Yes, excellent: 
At least for me, the moving tear line is always 
on the display which is *not* primary. 

Even works when switching on-the-fly, for already-running applications.
Comment 11 Michel Dänzer 2011-08-10 02:50:46 UTC
Great. Would this be a satisfactory resolution for this report?
Comment 12 Klaus Kusche 2011-08-10 03:45:07 UTC
(In reply to comment #11)
> Great. Would this be a satisfactory resolution for this report?

Well, as it seems to be impossible (at least for my combination of LVDS and DP) to have two (or even more) outputs in sync at the same time,
and as there is no way for the software to find out automagically which output
to sync, syncing to the primary output and depending on the user to set
the output he wants to have in sync using xrandr is the best we can get.

So: Yes.

But your patch was radeon-only. I think 
* all platforms should behave the same,
* and if they do, this behaviour should be documented somewhere.
Comment 13 Alex Deucher 2011-08-10 06:45:40 UTC
(In reply to comment #12)
> Well, as it seems to be impossible (at least for my combination of LVDS and DP)
> to have two (or even more) outputs in sync at the same time,

Unfortunately this is a hw limitation.  It can really only work in some very limited situations.  You would have to use identical monitors with identical modelines being driven by the same encoder types.  Even in your setup, if you could have used the same crtc, each monitor has different timing for the display so it likely wouldn't have worked as one of the displays may not have synced properly.

LVDS:
Modeline "1920x1200"x60.0  164.80  1920 2020 2052 2224  1200 1202 1208 1235 (74.1 kHz)

DP:
Modeline "1920x1200"x60.0  154.00  1920 1968 2000 2080  1200 1203 1209 1235 +hsync -vsync (74.0 kHz)
Comment 14 Michel Dänzer 2011-08-10 09:23:08 UTC
(In reply to comment #12)
> But your patch was radeon-only. I think 
> * all platforms should behave the same,

It's up to each driver.

> * and if they do, this behaviour should be documented somewhere.

I updated the radeon manpage paragraph about XV_CRTC.


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.