Red Hat Bugzilla – Bug 1290448
mutter is changing monitor layout from that set by xorg.conf
Last modified: 2016-11-03 21:42:19 EDT
Description of problem:
We have set a specific monitor layout in xorg.conf with 4 displays using Nvidia's metamodes (see attached xorg.conf). If you just start the Xorg process the monitor layout is correct. In this particular case monitor 1+3 are overlapped and 2+4 are overlapped. When gnome-shell is started and the gnome-settings-daemon runs, it changes the orientation around (lining up the displays). This occurs on a fresh installation where no user has ever logged in, so the login screen layout is not correct. See the layout changing in the Xorg.0.log file.
I have tried creating a monitors.xml file (see attached) and placing it in /var/lib/gdm/.config and this corrects the login screen, but once a user logs in the layout is once again changed.
Where can I set a default layout or how can I get gnome-settings-daemon xrandr to stop changing the layout defined in xorg.conf? I've tried placing a monitors.xml file in /etc/gnome-settings-daemon/xrandr but that had no affect.
On a related note, the gnome-control-center display settings applet does not support overlapping displays (i.e. cloning groups of displays). It only allows cloning all displays. There are cases were we need to clone only certain displays. Can you create an RFE for this feature?
Version-Release number of selected component (if applicable):
RHEL 7.2 with Nvidia Quadro M5000/M6000 and driver 352.63 with 4 displays attached over display port.
Steps to Reproduce:
I tried changing the default to /etc/gnome-settings-daemon/monitors.xml and
placing the file there but that didn't help. If I copy the same
monitors.xml file to ~/.config/monitors.xml then my layout is correct, but
that's not something we can do in general for users.
CU has a specific monitor layout in xorg.conf with 4 displays using Nvidia's metamodes (see attached xorg.conf). If you just start the Xorg process the monitor layout is correct. In this particular case monitor 1+3 are overlapped and 2+4 are overlapped. When gnome-shell is started and the gnome-settings-daemon runs, it changes the orientation around (lining up the displays). This occurs on a fresh installation where no user has ever logged in, so the login screen layout is not correct.
They have tried placing a monitors.xml file in /etc/gnome-settings-daemon/xrandr but seems to work sometimes and other times not, it's inconsistent.
Where can they set a default layout or how can they get gnome-settings-daemon xrandr to stop changing the layout defined in xorg.conf?
I did some more testing, and it appear that some times it reads the default from /etc/gnome-settings-daemon/xrandr/monitors.xml and some times it doesn't, but even when it does the geometry of the workspace is set to the equivalent of the 4 linear displays (or some times 3) even though 2 of the displays are overlapping so you end up with a large panning area. It seems very inconsistent.
If we can get this working correctly I'd be happy, but at the same time, requiring a monitors.xml makes is more difficult to set up a default if it is going to depend on specific monitors and serial numbers as hardware gets swapped in and out on a regular basis. I'd much rather it honor the layout defined in xorg.conf.
Created attachment 1104368 [details]
Created attachment 1104369 [details]
Created attachment 1104370 [details]
Created attachment 1104371 [details]
Created attachment 1104372 [details]
Reassigning to mutter as it's the one that's realigning the outputs on startup. If anything, it would be the one providing the setting to "not touch the monitor configuration".
As for supporting cloned groups of monitors, this is probably not something that we'd be interested in supporting in the configuration tool, but you can still file a bug, either here or upstream, explaining how or why this is an important feature to have available (rather than a one-off configuration which you can use once the above bug is fixed).
*** Bug 1302941 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.