Fix Monitors.xml Being Ignored Persistently Change Display Rotation

In this comprehensive guide, we will delve into the persistent issue of monitors.xml being ignored, particularly when attempting to change display rotation. Many users, including myself, have encountered frustrating situations where their meticulously configured display settings, achieved through tools like xrandr, are not consistently applied across system reboots or login sessions. This can lead to significant disruptions in workflow and overall user experience, especially for those who rely on rotated displays for specific tasks or ergonomic setups. Our primary focus will be on addressing this problem head-on, providing clear explanations, and offering practical solutions that you can implement to ensure your display rotations are consistently applied.

Whether you're dealing with bugged system settings or simply seeking a more reliable way to manage your display configurations, this guide is designed to help. We'll explore various methods, including the use of xrandr, configuration files, and custom scripts, to achieve persistent display rotation. By the end of this article, you'll have a solid understanding of how to troubleshoot and resolve issues related to monitors.xml being ignored, empowering you to maintain your preferred display settings without constant manual intervention.

The problem of monitors.xml being ignored is a common frustration for many Linux users, particularly those who customize their display settings beyond the default configurations. This file, located in the user's configuration directory (typically ~/.config/monitors.xml), is intended to store the layout and settings of connected monitors, including their positions, resolutions, and orientations. When the system starts or a user logs in, the display manager reads this file to configure the displays accordingly. However, there are several reasons why monitors.xml might be ignored, leading to inconsistent or incorrect display configurations.

One primary reason is that the display manager might not be properly reading or applying the settings stored in monitors.xml. This can occur due to bugs in the display manager itself, conflicts with other configuration files, or issues with the timing of when the display settings are applied during the boot process. For instance, if the display manager attempts to configure the displays before the graphics drivers are fully loaded, it may fail to apply the settings correctly, resulting in the system reverting to default display configurations.

Another contributing factor can be the use of multiple display configuration tools. While monitors.xml is the primary configuration file used by many desktop environments, tools like xrandr and arandr can also be used to modify display settings. If these tools are used without properly updating monitors.xml, the settings may be applied temporarily but will not persist across reboots. This discrepancy between the current display settings and the stored configuration in monitors.xml can lead to confusion and the persistent issue of settings not being retained.

Furthermore, permissions issues can also cause monitors.xml to be ignored. If the user does not have the necessary permissions to read or write to this file, the display manager may be unable to load or save the display settings, resulting in the system defaulting to its standard configuration. This can occur if the file's permissions are incorrectly set or if there are restrictions imposed by the system's security policies.

Many users initially attempt to configure their display settings through the system's graphical interface, which is designed to provide a user-friendly way to manage monitors, resolutions, and orientations. However, these interfaces are not always reliable, and users often encounter issues that prevent them from achieving their desired configurations. One common problem is that the settings may not be applied correctly or may not persist after a reboot, leading to frustration and the need for alternative solutions.

One specific challenge that users face is the unclickable "Confirm" button in the display settings. This bug prevents users from saving their changes, effectively rendering the graphical interface useless for configuring display rotation or other settings. When the "Confirm" button is unresponsive, users are left without a direct way to apply their desired display configurations, forcing them to seek command-line alternatives or manual configuration methods.

This issue often arises due to software bugs within the display settings application or compatibility problems with specific hardware or drivers. The unclickable button can be particularly perplexing because it gives the illusion that the settings can be modified, but ultimately prevents the user from finalizing the changes. This situation highlights the limitations of relying solely on graphical interfaces for display configuration and underscores the need for robust command-line tools like xrandr.

Moreover, even when the graphical interface functions as expected, the settings may not always be applied consistently. Users may find that their configurations are reset after a system update, a driver change, or even a simple reboot. This inconsistency can be particularly problematic for users who require specific display setups for their work or personal use, as it disrupts their workflow and necessitates constant reconfiguration. The lack of persistence in display settings is a significant challenge that many users face, making it essential to explore more reliable methods for managing display configurations.

Xrandr is a powerful command-line utility for managing display settings in Linux. It allows you to configure screen resolutions, orientations, refresh rates, and more. When graphical interfaces fail or don't provide the necessary flexibility, xrandr becomes an invaluable tool for achieving precise display configurations. Understanding how to use xrandr effectively is crucial for persistently changing display rotation and addressing issues where monitors.xml is ignored.

The first step in using xrandr is to identify the names of your display outputs. You can do this by running the command xrandr in the terminal without any additional arguments. This will output a list of connected displays along with their current settings. The output will show the names of your display outputs, such as DP1, HDMI1, or VGA1. These names are essential for specifying which displays you want to modify.

Once you have identified the output names, you can use xrandr to rotate your displays. The basic syntax for rotating a display is:

xrandr --output <output_name> --rotate <rotation>

Here, <output_name> is the name of the display output you want to rotate, and <rotation> is the desired rotation. The possible values for <rotation> are:

• normal: No rotation (default)
• left: Rotate 90 degrees counter-clockwise
• right: Rotate 90 degrees clockwise
• inverted: Rotate 180 degrees

For example, to rotate the display DP1 clockwise, you would use the command:

xrandr --output DP1 --rotate right

This command will immediately rotate the display clockwise. You can apply similar commands to other displays to achieve your desired multi-monitor setup. However, the changes made with these commands are temporary and will not persist after a reboot. To make the changes permanent, you need to ensure that these xrandr commands are executed every time you log in.

Achieving persistent display rotation requires ensuring that the xrandr commands are executed automatically upon login. There are several methods to accomplish this, each with its own advantages and considerations. We will explore three primary methods: using a startup script, modifying the .xprofile or .xinitrc file, and leveraging the display manager's autostart feature. Each of these approaches provides a way to automate the execution of xrandr commands, making your display rotation settings persistent across reboots and login sessions.

Method 1: Using a Startup Script

One common method is to create a startup script that contains the xrandr commands and configure the system to run this script during startup. This involves creating a shell script, making it executable, and then setting it to run automatically. Here’s how to do it:

1. Create a shell script:

   Open a text editor and create a new file, for example, rotate_displays.sh. Add the xrandr commands to this file. For example:

   #!/bin/bash
   

xrandr --output DP1 --rotate right xrandr --output DP2 --rotate left ```

Replace `DP1` and `DP2` with the actual names of your display outputs and adjust the rotations as needed.

2. Make the script executable:

   Open a terminal and navigate to the directory where you saved the script. Then, use the chmod command to make the script executable:

   chmod +x rotate_displays.sh
   

3. Add the script to startup applications:

   The method for adding a script to startup applications varies depending on your desktop environment. On GNOME, you can use the GNOME Tweaks tool or the Startup Applications Preferences. Add a new entry and specify the path to your script. On other desktop environments, such as KDE or XFCE, there are similar tools or settings to manage startup applications. Alternatively, you can manually add the script to the ~/.config/autostart directory by creating a .desktop file.

Method 2: Modifying .xprofile or .xinitrc

Another method is to add the xrandr commands directly to the .xprofile or .xinitrc file in your home directory. These files are executed when you log in to your graphical environment. The choice between .xprofile and .xinitrc depends on your system’s configuration:

• .xprofile is typically used by display managers like GDM and SDDM.
• .xinitrc is used when starting Xorg directly with startx.

Here’s how to modify the appropriate file:

1. Open the file:

   Open a terminal and use a text editor to open either .xprofile or .xinitrc. If the file does not exist, create it.

nano ~/.xprofile ```

or

```bash

nano ~/.xinitrc ```

2. Add the xrandr commands:

   Add the xrandr commands to the file. For example:

#!/bin/sh xrandr --output DP1 --rotate right xrandr --output DP2 --rotate left ```

Ensure that the file starts with the `#!/bin/sh` shebang.

3. Save the file and exit the editor.

Method 3: Leveraging the Display Manager’s Autostart Feature

Some display managers, such as LightDM, provide an autostart feature that allows you to run scripts or commands automatically during the login process. This method involves creating a .desktop file in a specific directory that the display manager scans for autostart entries.

1. Create a .desktop file:

   Open a text editor and create a new file, for example, ~/.config/autostart/rotate_displays.desktop. Add the following content to the file:

[Desktop Entry] Name=Rotate Displays Exec=xrandr --output DP1 --rotate right; xrandr --output DP2 --rotate left Type=Application X-GNOME-Autostart-Delay=2 ```

Replace `DP1` and `DP2` with the actual names of your display outputs and adjust the rotations as needed. The `Exec` line contains the `xrandr` commands to be executed. The `X-GNOME-Autostart-Delay` line adds a short delay before executing the commands, which can help ensure that the display manager is fully initialized before the settings are applied.

2. Save the file and exit the editor.

Even with the methods described above, you may encounter issues that prevent your display rotation settings from persisting. Troubleshooting these problems often involves checking the script's execution, verifying the display output names, and ensuring compatibility with your desktop environment and display manager. Let's explore some common issues and how to address them.

1. Script Not Executing

If the script or commands are not executing, the first step is to verify that the script is indeed executable and that it is being called correctly during startup. You can manually run the script from the terminal to check for any errors:

./rotate_displays.sh

If there are any errors in the script, such as typos or incorrect syntax, the terminal output will usually provide helpful error messages. Correct these errors and try running the script again.

If the script runs correctly manually but does not execute during startup, there may be an issue with how it is being called. Ensure that the startup application entry is correctly configured and that the path to the script is accurate. If you are using a .desktop file, verify that the Exec line contains the correct command and that the file is saved in the ~/.config/autostart directory.

2. Incorrect Display Output Names

A common mistake is using incorrect display output names in the xrandr commands. If the output names are wrong, the commands will not be applied to the intended displays. Double-check the output names by running xrandr without any arguments and verifying that the names used in your script or configuration match the output from the command.

3. Timing Issues

Sometimes, the xrandr commands may be executed too early in the startup process, before the display manager or graphics drivers are fully initialized. This can result in the settings not being applied correctly. To address this, you can add a delay before the commands are executed. For example, in a .desktop file, you can use the X-GNOME-Autostart-Delay key to introduce a delay:

X-GNOME-Autostart-Delay=5

This will delay the execution of the commands by 5 seconds, giving the system more time to initialize.

4. Conflicts with Other Configuration Methods

If you are using multiple methods to configure display settings, such as a startup script and a .xprofile file, there may be conflicts that prevent the settings from being applied consistently. It is best to choose one method and stick to it to avoid conflicts. If you have previously used other methods, ensure that they are disabled or removed to prevent interference.

5. Permissions Issues

Permissions issues can also prevent the script or commands from executing correctly. Ensure that the script is executable and that the user running the script has the necessary permissions to access the display devices. You can use the ls -l command to check the file permissions and the chmod command to modify them if necessary.

In conclusion, persistently changing display rotation on Linux systems, especially when monitors.xml is being ignored, requires a comprehensive approach. We have explored various methods, starting with understanding the limitations of graphical interfaces and the necessity of using command-line tools like xrandr. By learning how to identify display outputs and apply rotation settings via xrandr, you gain direct control over your display configurations.

The key to making these changes permanent lies in automating the execution of xrandr commands during startup. We have detailed three primary methods: using startup scripts, modifying .xprofile or .xinitrc, and leveraging the display manager's autostart feature. Each method provides a viable solution, and the choice depends on your specific system configuration and preferences. By implementing one of these methods, you can ensure that your display rotation settings are consistently applied across reboots and login sessions.

Moreover, we addressed common troubleshooting issues that users may encounter, such as script execution failures, incorrect display output names, timing problems, configuration conflicts, and permissions issues. By systematically checking for these potential problems, you can effectively diagnose and resolve issues preventing your display settings from persisting. Remember to verify script executability, double-check output names, introduce delays if necessary, avoid conflicting configuration methods, and ensure proper permissions.

Ultimately, mastering persistent display rotation not only enhances your user experience but also empowers you to customize your Linux environment to suit your specific needs. Whether you require rotated displays for ergonomic reasons, specialized tasks, or multi-monitor setups, the techniques outlined in this guide will help you achieve and maintain your desired display configurations. By combining the power of xrandr with effective automation methods, you can overcome the challenges posed by monitors.xml being ignored and enjoy a consistently configured display environment.