Add an option to ask autorandr to make all xrandr changes in one go about autorandr

[vincentbernat]

This could also include switching off unused inputs in the same pass. xrandr specifically turns them off first before turning the other outputs on.

[phillipberndt]

Yes, that's what I thought, too. See the single-pass branch. Does that work as expected?

[Vladimir-csp]

From my experience the main problem of manipulating xrandr in one go is the shortage of CRTCs. I tried to work around this, but settled for 2-pass algorithm: first disable everything that needs to be disabled, then enable everything that needs to be enabled.
Also, In the process of disabling output I preserve the framebuffer size so it won't become smaller than it needs to be at any point of transition. It's better for window managers, windows wouldn't be crammed into a small area.

[phillipberndt]

Yes, that's why autorandr doesn't do everything in one pass either. It even uses 3 passes in some cases (e.g., some drivers run into issues when it comes to --transform changes). This is about allowing users who aren't affected to tell autorandr to do everything in a single pass using a command line option, not about changing the default.

Also, In the process of disabling output I preserve the framebuffer size so it won't become smaller than it needs to be at any point of transition. It's better for window managers, windows wouldn't be crammed into a small area.

That's a good idea for an improvement, thanks!

[Vladimir-csp]

Glad to be of help. I wanted to beef up my python skills and rewrite rerandr on python, but looks like I don't need it anymore )

[Vladimir-csp]

BTW, I've added some input on DPI handling

[vincentbernat]

For what is worth, I am now using autorandr without any issue. I don't remember why I have requested to avoid triggering too many RandR events, but as it works as is, I think this is better to avoid supporting multiple code paths.

[seqizz]

Sorry for necrobumping a bit.

I've tried to rebase this single-xrandr-pass feature to current master. Weirdly, it fixes the issue I am facing right now with the Dell XPS 13 + dockstation + 2 monitors. I didn't understand actually why, but if it's not a single xrandr command, dock monitors stays disabled, even though xrandr reports them as on and autorandr reports switch happened with some minor gamma/crtc warnings.

Again, thanks for the effort you've put into this tool.

[bdowning]

I also seem to have a device (Lenovo P1 Gen5, which is Intel/nVidia hybrid with the internal panel switchable between the two via a bios setting and the external ports hardwired to the nVidia 🙁 - I'm in hybrid mode driving the external monitors with Reverse PRIME) and X environment (XMonad with no desktop environment) where the default autorandr behavior doesn't work properly here.

Autorandr wants to run the following to switch from undocked to docked:

xrandr --fb 7040x1440 --output eDP-1 --crtc 0 --gamma 1.0:1.0:1.0 --mode 1920x1200 --pos 0x0 --primary --rate 59.88 --reflect normal --rotate normal --set 'Broadcast RGB' Automatic --set Colorspace Default --set 'max bpc' 12 --set non-desktop 0 --set 'scaling mode' 'Full aspect' --output DP-1-0.2 --crtc 4 --gamma 1.0:1.0:1.0 --mode 2560x1440 --pos 1920x0 --rate 59.95 --reflect normal --rotate normal --set non-desktop 0 
xrandr --fb 7040x1440 --output DP-1-2.2 --crtc 5 --gamma 1.0:1.0:1.0 --mode 2560x1440 --pos 4480x0 --rate 59.95 --reflect normal --rotate normal --set non-desktop 0 
xrandr --fb 7040x1440 

doing so results in my third screen not being functional - it just shows the X background color, and while focused and hitting my switch desktop keys it switches the desktop on the second screen. If I instead run:

xrandr --fb 7040x1440 --output eDP-1 --crtc 0 --gamma 1.0:1.0:1.0 --mode 1920x1200 --pos 0x0 --primary --rate 59.88 --reflect normal --rotate normal --set 'Broadcast RGB' Automatic --set Colorspace Default --set 'max bpc' 12 --set non-desktop 0 --set 'scaling mode' 'Full aspect' --output DP-1-0.2 --crtc 4 --gamma 1.0:1.0:1.0 --mode 2560x1440 --pos 1920x0 --rate 59.95 --reflect normal --rotate normal --set non-desktop 0 --output DP-1-2.2 --crtc 5 --gamma 1.0:1.0:1.0 --mode 2560x1440 --pos 4480x0 --rate 59.95 --reflect normal --rotate normal --set non-desktop 0
xrandr --fb 7040x1440

i.e. all setup commands crammed together into one call, things work properly.

Anyway, I'll take a look and see if I can get this working as an option at some point, mostly I'm just reporting in here.

(Thinking this could be an XMonad issue, maybe if it detects desktops only when it sees a framebuffer resize? Not sure. Even if so I feel less confident in being able to fix that than getting autorandr to optionally cram all setup together though. 🙂)

[phillipberndt]

If you primarily need to reset the fb size again as a last step, would a post switch hook do the job for you, too?

Generally, my preferred way to work around all the various quirks would be to find a way to fix this issue for you without any extra options and/or breaking things for others.. e.g. one thing we IIRC haven't tried yet here is activating the displays in a different order. What happens if you activate the last screen as part of the first batch? The only constraint is that the top/left screen has to be activated as part of the first command, IIRC.

[bdowning]

OK, confirmed that after getting it into the "wedged" configuration if I then run:

xrandr --fb 7041x1440
xrandr --fb 7040x1440

just to force a framebuffer resize, that kicks xmonad into properly detecting things. Kind of annoying but I can work with that for now.