Bug 39696

(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.

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).

(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?

(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.

(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.

(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

(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?

(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...

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?

(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.

Great. Would this be a satisfactory resolution for this report?

(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.

(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)

(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.