Additional Documentation about autorandr

[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

[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]

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?

[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.

[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?