On Wed, Jun 10, 2015 at 6:12 PM, James Feeney james@nurealm.net 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".
It's still a challenge even if you printed information about the clock sources. As Christian noted, there are a lot of corner cases and limitations of various clock sources depending on the chips. E.g., just printing out that you have 3 clocks sources does not imply that you can run 3 monitors. E.g., ext pll can only drive native DP or active DP to DVI converters. Regular plls can only be shared if the clocks match, etc. I'm not sure if it would help or just cause more confusion.
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?
Part of the problem is the current KMS modesetting API. It sets modes per display rather than globally setting up the entire display configuration. For example some DIG PHYs (encoders for digital displays like DP or HDMI or DVI) can only be driven by certain PLLs. If the PLL is already in use by another display, the driver cannot support the requested configuration without reconfiguring the the other already configured displays so the ordering may make a difference. The new atomic modesetting API that is currently in progress aims to rectify this by setting up the complete display state at one time so the driver can make optimal decisions about how to use the relevant display resources.
Alex