Additional Documentation

[MrGamy]

Hi Phillip,

I am currently having a hard time finding information on how to get autorandr to run whenever a display is connected or disconnected. I am aware that there are systemd .service files, and I've read some issues taking about udev rules as well. But I can't really find clear information on how to initially set this up. I also noticed the same problem regarding autorandr + $locker issues (display changes after sleep, revealing the desktop bcs. lock stays on the previous display ; also a locker issue but still)

I also saw that autorandr_launcher exists, but I suspect it's not part of the arch package, instead being on the aur, right?

Would it be possible for you to write some additional documentation for these things?

[haunma]

Adding to this (hopefully in a constructive fashion :), it would be really nice to understand how autorandr gets run on a display connection/disconnection. I originally assumed that autorandr was a daemon process running in the background. Lots of folks are autostarting it in the window-manager startup files, etc. But lo! there is no autorandr process running on my system. And yet, somehow it is triggered on display changes. I have looked and looked and have not been able to figure out how that happens. Understanding this has implications for how and when autorandr should be run (from a startup file or wherever), and it would be nice if the documentation explained this magic. Is it registering a "callback" from some system service?

[laur89]

And yet, somehow it is triggered on display changes. I have looked and looked and have not been able to figure out how that happens

Came here with the same question. On debian system (installed from apt), I can see two systemd units being active:

/etc/systemd/system/sleep.target.wants/autorandr.service
/etc/systemd/system/multi-user.target.wants/autorandr-lid-listener.service

first for triggering when resuming from suspension, and second triggering when laptop lid is opened. Nothing under udev. How are actual display changes picked up?

---

Edit: found it, the udev rule is installed into /lib/udev/rules.d/40-monitor-hotplug.rules

[haunma]

Hey, nice catch! Thanks for tracking that down.

Next question, I suppose, is whether we should be running autorandr anywhere in .xinitrc or autostart scripts (thinking specifically of "startx" setups like mine, without a display manager). If it is already called on every display change, maybe there is no reason to run it manually, ever.

[laur89]

I never run it manually under normal circumstances.

[phillipberndt]

What complicates answering this question is that autorandr supports many, many different ways of being used, and the package itself installs a random collection of automation tools. I treat the repository as containing a script that people can setup manually however they'd like (the tool is clearly aimed at powerusers that heavily customize their system these days, not at the average user - let's face it, WMs got quite good at managing screens on their own 😉). Different package maintainers then enable different kinds of automation in their packages, according to their taste.

A few options are:

• Use a systemd unit + udev - this is the default. An udev rule fires whenever something changes and activates the systemd unit, which runs autorandr in a batch mode where it runs itself for every user that has an open X11 session.
• An autostart desktop unit to run autorandr exactly once at startup
• pmutils integration to run autorandr whenever the system wakes up from sleep
• A daemon that runs in your X11 session and runs autorandr whenever there's a screen change event - that's the launcher from the contrib repo.
• listen_lid - from the contrib directory, is a script to listen for lid events on laptops, and then runs autorandr

I think what I'd currently prefer is an option we don't currently have: Use ctypes from autorandr itself to reimplement autorandr_launcher, and then just give it a --daemon option that utilizes it and put autorandr in daemon mode into people's autostart. The reason I'd prefer this nowadays is that it doesn't have extra dependencies, works for everyone no matter which distribution, and is dead simple to understand - as you wrote, it's natural to expect a daemon :)

[haunma]

Thanks for the detailed explanation! I personally like the fact that it's not another daemon on my system---so many of those already. The udev (eudev sans systemd on my Void Linux laptop) method seems pretty straightforward.

[laur89]

Agreed, don't see anything wrong with utilizing the hooks provided by the OS itself -- why have yet another service running in the background when it's not really needed?