Daemon mode, watching for monitor changes

[nomeata]

There is a very simple tool that waits for the X server to tell it about changes in the monitor configuration, which then executes a command: http://portix.bitbucket.org/srandrd/

While this can be easily combined with autorandr, I don’t think it’d be a bad idea to just integrate this into autorandr, e.g. as a daemonizing autorandr --watch mode.

[phillipberndt]

This can (and has been) also be implemented using udev in https://github.com/phillipberndt/autorandr/commit/6bdb12f4882253dda5e1ef38db6dcc3d2a3463aa, avoiding the overhead of an additional process.

[nomeata]

I know about that solution, but I don’t think that its the proper one: It requires root access, and weird tricks to find the right X server.

And an additional process that just blocks until the X server sends the right event is no real overhead.

[phillipberndt]

That's right. But I still don't see the benefit of a command line option for this, when a simple one-liner Xsession script with

srandrd autorandr -c

could do the job just as well? I'd pull an according script to the contrib directory if you'd like..

Btw., there also is autorandr_monitor by @QueezyTheGreat, accomplishing the same goal, via an inotify watch on /sys/class/drm/**/status. Admittedly, srandrd might be the simpler tool here.

[nomeata]

The benefit would just be one package less to find and install (especially for something that trivial), and easier discoverability if autorandr --help mentions it. (And less exec’s, but that’s irrelevant :-))

But maybe it is indeed enough to point to srandrd in the README and the manpage.

[phillipberndt]

autorandr is a shell script; you'd still have to install srandrd in any case.

[nomeata]

Oh, for some reason I assumed autorandr was a C program, talking directly to the X server using the randr protocol. Not sure why I thought that, though – sorry. (As you can tell, I’m not using it yet, I was just doing the planning so far :-))

[nalipaz]

for those whom might want the option to monitor and automatically configure I have written up another option. https://github.com/nalipaz/poll-xrandr

There is a .deb under the releases page. I chose the polling method since udev does not detect the added displays on my system, likely a bug in udev or my hardware drivers.

The linked project requires autorandr to work.

[phillipberndt]

Does standrd also not work for you? (The benefit over your method would be that it doesn't require to poll every so often..) I'm asking because I recently translated the source to python https://github.com/phillipberndt/autorandr and adding srandr's functionality there (optionally, if python-xlib is available) would be an option.

[nalipaz]

srandr did not work for me, independently nor using the python version of autorandr, both of which I already tried. In my research I was able to surmise that there is some hardware that just doesn't seem to reliably communicate with udev. Whether that is maturity level of udev, lack of support in drivers, or a bug elsewhere I can't say. But a quick google for "hdmi udev rules not working" turns up a good deal of results.

BTW, I did test udev directly using monitor and only ever saw my hdmi plug/unplug cause an event 1 time out of every 20.