Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Make Cinnamon/Gnome respect the /etc/X11/xorg.conf file instead of ~/.config/displays.xml

Make Cinnamon/Gnome/Mate Respect xorg.conf

By default the Cinnamon/Gnome/Mate desktop environment loads its own display configuration from the file ~/.config/monitors.xml instead of using the settings defined in /etc/X11/xorg.conf. This can be a little bit annoying if you are using the nvidia-settings program to configure your displays (which will use xorg.conf), since anything entered there will be overridden by monitors.xml every reboot.

By doing the following changes we will disable the "Display Manager" in Cinnamon/Gnome/Mate, and make the system default back to using the xorg.conf settings again.

ℹ️ Before you begin to mess around with your system, please make a backup of your files!

⚠️ Read this section if you are adding/removing monitors frequently.

Disable the XRandR Plugin

The offending program is the "xrandr" plugin for the <cinnamon/gnome/mate>-settings-daemon. This is responsible for managing the resolution, refresh rate and positions of your screens, and is basically what you control if you open the System Settings > Display menu. Things you change there will be written to the ~/.config/monitors.xml file, and is what is applied during the startup of the computer.

Some people have suggested that it should be possible to just remove the file ~/.config/monitors.xml, in order to to stop the unwanted behavior, but this was not enough for me. I had to disable the entire xrandr plugin before it would stop messing with my settings.

Disabling this plugin is done a little bit differently depending on your current desktop environment, so please make sure you choose the correct option below. After disabling it I was able to modify my display settings via the "NVIDIA X Server Settings" program, save the config, reboot my computer and all all would be good.

This info was composed primarily from this nice StackOverflow post, but I added some extra info from a couple more sources [1], [2], [3].

Cinnamon

Version > 3.4

For this I have been able to find three different methods, which all seem to be possible to do. Test which one works best for you.

  1. Disable it via System Settings

Open up the System Settings > Startup Applications menu, and set the startup entry Cinnamon Settings Daemon - xrandr to OFF.

  1. Override the .desktop file.

Make a copy of the cinnamon-settings-daemon-xrandr.desktop file in your user's $HOME/.config/autostart/ folder, to override the system wide one, and add Hidden=true to the end of the new file in order to disable the plugin.

cp /etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop $HOME/.config/autostart/
echo "Hidden=true" >> $HOME/.config/autostart/cinnamon-settings-daemon-xrandr.desktop
  1. Move/rename/delete the .desktop file.

If none of the above works, you can just make the cinnamon-settings-daemon-xrandr.desktop file unrecognizable for Cinnamon by moving/renaming/deleting it.

sudo mv /etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop /etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop.disabled

Version ≤ 3.4

In earlier versions of Cinnamon there exists only one option, and that is running the following command.

gsettings set org.cinnamon.settings-daemon.plugins.xrandr active false

Gnome

Version > 3.1.3

The option to disable individual plugins was removed in newer versions. Seems to be handled by Mutter now.

Version ≤ 3.1.3

gsettings set org.gnome.settings-daemon.plugins.xrandr active false

Mate

gsettings set org.mate.settings-daemon.plugins.xrandr active false

Other Nice to Know Stuff

Make a Backup of the Old Config Files

When fiddling around with new settings, it is always recommended to make a backup of the files which you are editing. Here are therefore two quick commands that can be run in order to make a copy of the two files which are being edited in this guide:

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
cp ~/.config/monitors.xml ~/.config/monitors.xml.bak

Note to Those Who Swap Monitors Often

Disabling of the desktop environment's "Display Manager" may result in worse handling of changes to the desktop layout when displays are added/removed. This is probably irrelevant for a workstation, with a static screen setup, but might become bothersome on a laptop which you repeatedly plug in an external screen to.

When a monitor is removed from the computer, the "Display Manager" (basically the xrandr plugin in this case) is made aware of this event and will call upon the xrandr program to update the display configuration and then change the layout of your desktop to conform to the now missing screen. This would also include stuff like moving all your windows to the remaining monitor, and stopping the mouse form going over to the area where the old monitor was. However, when disabling the desktop environment's "Display Manager" some of these change events might not trigger correctly.

The proprietary Nvidia driver has similar support for adding/removing screens, and will send out the correct commands to the xrandr program in order to update display configuration to the new layout.

This is a configurable option, which is called UseHotplugEvents, and can be disabled if you do not want the computer to react at all to you changing displays.

However, since this is not done from the desktop environment's "Display Manager" it seem like not everything in Cinnamon/Gnome/Mate will be notified in the correct way. From some quick testing it seems like Cinnamon handles it pretty well, but I noticed that the taskbar would not properly propagate to the new display when I added one. This was remedied by issuing a restart of Cinnamon through pressing Alt+F2, typing r in the text field that popped up and then pressing enter. This now made everything work as expected again.

Saving the Nvidia Settings

When clicking the "Save to X Configuration File" button, in the "NVIDIA X Server Settings" program, you might run into this error message:

You do not have adequate permission to open the existing X configuration file
'/etc/X11/xorg.conf' for writing. You must be 'root' to modify the file.

This usually happens if you start the program via the "Start Menu", since then you will launch the program as your current user. If we take a look at the permissions of the xorg.conf file we see this:

-rw-r--r--   1 root root 1.8K Mar 10 10:57 xorg.conf

This means that your current user (and thus the Nvidia program) does not have permission to write to that file, just like the error message says. The solution is to start the program as root instead, and that is most easily achieved by launching it via the following terminal command:

sudo nvidia-settings

Do your changes, and press save. If you do not have any other programs that have added changes to this file, it might be a good idea to uncheck the "Merge with existing file." option in the save dialog, to make sure there are only Nvidia settings present in the file.

Other Locations for xorg.conf

The xorg.conf file may be located at a lot of other places, and the Xorg server program will read the different files in the following order (if it is started as 'root'):

  1. <cmdline>
  2. /etc/X11/<cmdline>
  3. /usr/etc/X11/<cmdline>
  4. $XORGCONFIG
  5. /etc/X11/$XORGCONFIG
  6. /usr/etc/X11/$XORGCONFIG
  7. /etc/X11/xorg.conf
  8. /etc/xorg.conf
  9. /usr/etc/X11/xorg.conf.<hostname>
  10. /usr/etc/X11/xorg.conf
  11. /usr/lib/X11/xorg.conf.<hostname>
  12. /usr/lib/X11/xorg.conf

This Won't Be "Fixed"

This is treated as expected behavior by the developers, and thus the xorg.conf file will not be honored if you are running either of the mentioned desktop environments. There are a few GitHub issues discussing this, and people being told that this is how it is supposed to be:

So this guide is currently the best/only option if you are using the nvidia-settingsprogram to store your display configuration under Cinnamon/Gnome/Mate.

The "fix" outlined in this guide actually seems to be the method endorsed by the same guy who previously said that this won't be fixed in the issues listed above... (o.O)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment