[Bug 99103] Same output (DisplayPort) is used in multi-head configuration for different Devices/Displays

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Dec 19 12:01:52 UTC 2016


https://bugs.freedesktop.org/show_bug.cgi?id=99103

--- Comment #5 from Stefan.LAUTERWASSER at thalesgroup.com ---
(In reply to Michel Dänzer from comment #4)
> In short, this configuration (Zaphod style, with 4 screens per GPU) isn't
> supported. The radeon driver only supports 2 screens per GPU in Zaphod mode.
Sorry, I saw the restriction of 6 monitors per GPU and didn't saw any
restriction of 2 screens per GPU - I may overlooked.

Is the limit simulated or by design? I have an idea of the differences
supporting one or two, but didn't understand the differences in supporting two
or six screens - the idea of fragmentation exists already.
You don't need to explain in details, but if you are able to refer to some
background information - I am just a bit stupid and nosy.

> Unless you really need multiple X11 protocol screens and/or static
> configuration in xorg.conf, I'd suggest trying without xorg.conf and letting
> the desktop environment manage the display configuration via RandR 1.4. Note
> that in this case I highly recommend using at least the xf86-video-ati 7.8.0
> release, possibly even current Git master, and ideally a newer version of
> Xorg as well.
We use only X server with openbox - not that rich desktop environment.
I tried to configure with xrandr command but I have no idea how to create
displays without xorg.conf and I don't know how to bind a output to a display.
I am able to create displays and output binding with xorg.conf only, can you
show me a different way/command?
But if the driver doesn't support more than 2 screens how can xrandr help?

> Alternatively, you could try combining two displays per Zaphod screen, but
> I'm not sure that'll work out.
Our safety concept currently does not allow more than one monitor per screen
and display - we change that in future if we have to, but currently cannot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-driver-ati/attachments/20161219/36e8ddff/attachment.html>


More information about the xorg-driver-ati mailing list