On 11.06.2015 00:12, James Feeney wrote:
Yes, DP needs its own clock source. However, you only need one clock source
for all DP ports so you can drive multiple DP displays from a single clock
source. The clock source used for DP cannot be shared with non-DP displays.
...
There are additional caveats however. For example, you can't
share a clock source between two displays with different hdmi audio settings
even if the mode clocks are the same
Again, thanks for that. That's quite helpful. In extensive reading, trying to
understand what would be required to run three displays, I saw no mention of
those two points.
If the radeon driver could report a) what architecture it sees/code path it is
following, b) the total number of clock sources found, and c) which clock
sources are assigned to which outputs, then it would be much easier to discover
the current display configuration and to anticipate what display configurations
would be "workable".
Yeah, that's indeed true. We already dump the connector configuration on
bootup, but not the config of the PLLs driving them.
Feel free to submit a patch for this, it clearly sounds like a good idea.
The radeon driver can be quite "obstinate" when trying to set a specific
configuration for three displays, where the result will depend upon the
configuration history, or perhaps is strongly dependent upon the relative
position of the displays.
For instance, with my HD 5570, and supposing that the external clock is not
installed, and that there are still two independent internal clock sources
available, it should be possible to assign one clock source to the DisplayPort
output, and one clock source shared to the DVI and HDMI outputs. If I change
the output modes from a working configuration to, say, a test configuration, and
then try to change back again, some repeated "trial and error" attempts with
xrandr are required, before the original configuration will "take". Often, the
first reconfiguration or two results in some black screens, and then "something"
in some subsequent xrandr reconfiguration will trigger a screen update where the
displays are first "scrambled" and then are redrawn correctly.
This suggests to me some kind of "hidden state" in the radeon driver, which is
being updated by some indirect mechanism when I change output modes. Sorry, I'm
not being precise. Does anyone have any thoughts about how to better understand
this reconfiguration sequence, and how to make the process more "robust" and
predictable?
Well, the basic problem is the hardware. And the "hidden state" you are
talking about is just the hardware state.
Especially on older generations you have all kind of funny dependencies
in the PLLs that you need to take care of in the software.
Some have special routing requirements, e.g. can drive only certain
outputs, some can only generate a certain range of frequencies
(resolutions), some have undocumented power management dependencies
(e.g. you turn PLL1 off and PLL2 suddenly becomes unstable).
The last time I tried to fix some corner cases I've broken a lot of
other users with my patches. So a very typical scripting comment applies
here as well: "It works don't touch it"! We could try patches, but the
chance of fixing it for one person and breaking it for somebody else is
just very high.
The best advice I can give you if you want to use more than two displays
at the same time make sure to have DP displays, and that's a good idea
no matter what hardware you have.
Regards,
Christian.
James
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
