autorandr
autorandr copied to clipboard
xrandr shows monitor connected but autorandr always switches back (ext. monitor screen stays black)
Autorandr works great for my external monitor at home, but at work I have the following issue:
-
Without autorandr: If I come to work in the morning the screen stays black even after applying my settings (saved from arandr). xrandr does however pick up the screen as an output even if it's black. So it seems to be some kind of a standby-mode that will not react to HDMI output. To make it work I always have to manually press the some buttons on the monitor to "wake it up". The monitor is a Samsung LS32A800NMPXEN. Any idea what the problem is here?
-
With autorandr: Above issue also seems to influence the behavior of autorandr, because once I plug the monitor in it tries to apply the saved setting for the external Samsung monitor (which it detects), however then it immediately switches back for reasons I don't understand. I have hooked the postswitch with
notify-send -i display "Display profile" "$AUTORANDR_CURRENT_PROFILE"
to check that this is what is actually going on and it confirms above assumption.
I'm not an expert in monitors, but maybe someone could point me into the right direction. The optimal solution would be for the monitor to immediately start streaming once I plug in the HDMI cable ( which is the case for my home monitor (Alienware)). Are there known issues like this with some samsung screens or is this unrelated?
Furthermore I'd like to understand where this switching forth and back behavior is coming from. Does autorandr react on other triggers than just HDMI plugged in?
I'm facing the same problem myself, and for me, the reason is that the graphics driver and monitor don't play well together, especially if multiple screens are connected via daisy chaining. Upgrading to the latest OS (Ubuntu 20.04 -> 24.04 in my case) allegedly helps a lot.
I haven't found a good workaround without upgrading, I so far just retry until it works.
I haven't tried systematically sending dpms comments to the black screens. (xset dpms force ..)
@phillipberndt I heard that graphics cards are always a bit of a problem on linux, but I'm happy to hear that this got better with the new Ubuntu (I'm currently using 22.04). So I'm going to try to update soon. What are dpms comments?
This sounds like the problem I'm currently dealing with. Hardware and software I'm using:
- Dell Latitude 7490
- Samsung 32" UJ590 UHD Monitor
- Ubuntu 24.04.1
- AwesomeWM
I just installed Ubuntu and AwesomeWM last week, been wrestling with external and laptop monitor strangeness since then. I have 2 autorandr configurations setup: one for using an external monitor with the laptop shut (multi) and another for working with the laptop without an external monitor (mobile).
My problem right now is when the laptop is in clamshell mode, charging, with the external monitor plugged in via HDMI.
Things are fine until the laptop goes to sleep. When I attempt to wake it, the external monitor turns back on, though remains black, and seems like it's about to display the desktop. Then it will go back to sleep. I must open the laptop lid to interact with the machine at this point. If I run the autorandr command manually, the external monitor will turn on for a moment, display the desktop, but immediately turn back off and revert to the laptop screen. To work around this, I've been restarting AwesomeWM, then after logging back in the multi configuration kicks in and everything is working as expected.
@jh3 That sounds very similar. What happens if you create a profile that uses your external monitor with arandr and activate that? Will the monitor automatically be awoken from sleep or will it remain black until you fiddle around with the monitor buttons? In my case I have to somehow manually wake it up using the monitor buttons until I see something.
@MartyMcFlyInTheSky So I just tried messing with the monitor power button and it saved me from needing to restart AwesomeWM/log out:
- Laptop (in clamshell mode) went to sleep, external monitor turned off
- As expected, attempting to wake laptop did not fully re-activate the external monitor
- Opened laptop, turned monitor on/off via power button
- Ran the autorandr command to activate my external monitor configuration
- External monitor turned on, laptop screen shut off 🎉
I see this sequence of logs a few times in /var/log/syslog:
2025-01-27T09:49:56.470216-05:00 autorandr[85651]: Failed to load profile 'default': Profile not found (line 1644)
2025-01-27T09:49:56.470359-05:00 autorandr[85651]: autorandr running as user jh3 (started from batch instance)
2025-01-27T09:49:56.470392-05:00 autorandr[85651]: mobile (current)
2025-01-27T09:49:56.470415-05:00 autorandr[85651]: multi
2025-01-27T09:49:56.491599-05:00 autorandr[85637]: Running autorandr as jh3 for display :0
2025-01-27T09:49:56.500095-05:00 systemd[1]: autorandr.service: Deactivated successfully.
2025-01-27T09:49:56.500383-05:00 systemd[1]: Finished autorandr.service - autorandr execution hook.
I'm not sure why autorandr is trying to load a profile named default. Also not sure why the mobile configuration was considered the current config. My guess is that when the monitor goes to sleep, it switches to the mobile configuration.
@MartyMcFlyInTheSky Just noticed something new: after my laptop/monitor are 'sleeping', if I open the laptop and attempt to load the autorandr config for my external monitor twice, it will work.
The first time I try loading it:
- Laptop monitor turns off (expected, part of the configuration)
- The external monitor comes back on (remains black), looking as if it'll soon show the desktop
- External monitor does nothing else, but remains on; laptop screen turns back on
Now with the external monitor on and the laptop screen on, I can quickly run the autorandr -l <config> command again, a this time it works. I assume the key piece is that the external monitor is already on, but not yet displaying anything. Not sure how to confirm this, but it seems like autorandr doesn't wait for the external monitor to completely turn on. If there was a 1-2 second pause during the execution of the command so that the monitor could "catch up", I think it would work as expected.
@jh3 That's something I also thought about. There seems to be two states regarding the monitor (I haven't confirmed this with the source code...). But there seems to be a state "connected" in which autorandr and xrandr will detect the monitor. And something like "active" where the monitor actually consumes the signal and displays it. It seems like our monitors are a tad bit too slow in showcasing the "active" state to autorandr so that it will refrain from sending any signals and revert back to the previous configuration. In our case this active state can be enforced by fiddling with the power buttons. I'm wondering if this behaviour is fixed on wayland.
@MartyMcFlyInTheSky re:wayland - I think this is somewhat related: I recently tried out Wayland via Hyprland on Ubuntu and Arch (as opposed to Ubuntu+i3+x11). Things were pretty smooth for a while on Ubuntu, and then I started running into a "red screen of death" when waking up the laptop. I believe it always (and only) happened when connected to my external monitor. I moved to Arch, and the red screen stopped (!), but I still encountered the same problem. It just came with a Hyprland error message this time that allowed me to restart the desktop environment.
So, not using [x|auto]randr, not directly anyway (or maybe at all), in this case, but it certainly still feels like the same issue.