[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