autorandr might be run too early after resuming about autorandr HOT 12 CLOSED

I think I have a fix for this issue. I might have misunderstood it though, in which case I am sorry for wasting your time.

In any case, I am (unfortunately) using systemd, and I have a working autorandr in 56612c2. That commit works for me both for suspend and udev events.

The last commit also seemed to work on my machine, but only for suspend and only some of the time.

The problem seems to be that the command in RUN+= is run before the xrandr list has been updated, and udev will not update the list until the script has finished. The obvious solution to this is to do something similar to what you do, by forking.

However this approach will not work for the udev that is part of systemd. This is a quote from the man-page of udev on my machine:

Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.

My work-around is to simply start the service from the udev script. This service will then run when the udev handling is done.

The only thing that is not working in that commit is the following strange scenario:

• Suspend the system
• Plug in a screen
• Start up the system
• We will run autorandr just after boot, which will not detect the screen
• A udev event will not trigger
• At some later point, I will run xrandr, which will at that time trigger a udev event, and thus run autorandr.

To fix that scenario, I have another script that will run xrandr every second for 20 seconds after a suspend.

from autorandr.

Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.

A correction, unless I missed something while skimming through the code this does work with systemd-udev, only not on systems using systemd's init. udev creates a cgroup and regularly kills all processes only on systems using systemd's init. On other systems, child processes seem to be ignored, and foreground processes have a default timeout of 180s, which surely is enough, and are SIGKILLed then.

How about, instead of changing the udev rule to run the script through systemd, we patch the 40autorandr script and udev rule. This should maintain compatibility with other init systems:

40autorandr:

# Add to start
if grep -q systemd $(readlink -f $(awk '{print $1}' /proc/1/cmdline)) && [ "$2" = "udev" ]; then
    exec /bin/systemctl start autorandr-resume.service
fi

autorandr-resume.service: Add Type=forking.

udev script: ACTION=="change", SUBSYSTEM=="drm", RUN+="/etc/pm/sleep.d/40autorandr thaw udev"

from autorandr.

I do not understand why Type=forking is needed, however the other change seems reasonable. I will test it now.

from autorandr.

I have implemented your suggestion in 7d127f5. That still works on my system.

from autorandr.

Type=forking is needed (I guess?) if you leave the detect_display & as is. Does that work as well? I'd prefer that, because elsewise udev will block until the script has completed on non-systemd systems.

from autorandr.

I had a few issues while experimenting with Type=forking, but they might not have been related to that.

The downside with that approach is that you have to wait 5 seconds, which I would prefer not to -- my current setup works instantly.

I will test it in a few hours.

from autorandr.

The downside with that approach is that you have to wait 5 seconds, which I would prefer not to -- my current setup works instantly.

@blueyed, could you check if this applies for you as well?

from autorandr.

I had no issues with inserting Type=forking and replace detect_display with detect_display &. I still don't have the sleep 5 though.

As I said previously: The only issue I have is udev will sometimes not send an event if I plug in a screen while the machine is in standby. In that case I need to run xrandr at some point after initialization to force the event to occur.

I simply have a loop that runs xrandr a few times a second for 25 seconds after opening the lid.

from autorandr.

Do you want me to do a PR with my changes?

from autorandr.

@blueyed needed the 5 second delay on his system, I'd like to wait for his opinion on its removal, but afterwards, sure, that'd be geat.

from autorandr.

The 5 seconds delay was just a guess to resolve this issue, but I'd rather not have it, too.

from autorandr.

@blueyed What I was after was whether @idolf's solution also mitigates this issue, or whether a delay is still needed!? I'll assume it did.

@idolf I merged your changes & added you to the author list.

from autorandr.