You are not logged in.
Have the following rule saved under /etc/udev/rules.d/95-monitor-hotplug.rules
KERNEL=="card0", SUBSYSTEM=="drm", ACTION=="change", ENV{HOTPLUG}="1", ENV{DISPLAY}=":0", ENV{XAUTHORITY}="/home/user/.Xauthority", RUN+="/bin/bash /home/user/hotplug.sh"
Where hotplug.sh is:
#!/bin/sh
# Get out of town if something errors
#set -e
HDMI_STATUS=$(</sys/class/drm/card0/card0-HDMI-A-1/status )
if [ "connected" == "$HDMI_STATUS" ]; then
/usr/bin/xrandr --output eDP1 --auto --output HDMI1 --auto --right-of eDP1
/usr/bin/notify-send --urgency=low -t 5000 "Graphics Update" "HDMI plugged in"
else
/usr/bin/xrandr --output HDMI1 --off
/usr/bin/notify-send --urgency=low -t 5000 "Graphics Update" "External monitor disconnected"
exit
fi
Thing is, it works fine - it allows me to plug another monitor in and have xrandr run automatically; it just takes a good 20 seconds for either command to run.
The command
udevadm monitor --property
picks up the change events for drm/card0 instantly, so I'm not sure what the hold-up could be. Any ideas?
Last edited by USRapt0r (2018-06-13 01:33:15)
Offline
notify-send operates on dbus, you didn't export a DBUS_SESSION_BUS_ADDRESS and the default dbus timeout is 25 seconds.
Online
Thanks for the reply.
printenv DBUS_SESSION_BUS_ADDRESS gives:
unix:path=/run/user/1000/bus
Not sure why that would matter anyway, as xrandr should be executed first.
Offline
Is DBUS_SESSION_BUS_ADDRESS really available whenn the script is invoked by udev?
You didn't say that the randr call alone would take 20 seconds.
I'd suggest to measure the behavior, ie. inject some "date >> /tmp/
echo "connected" >> /tmp/debug_my_udev
date +"xrandr: %c" >> /tmp/debug_my_udev
xrandr --output eDP1 ... >> /tmp/debug_my_udev 2>&1
date +"notify: %c" >> /tmp/debug_my_udev
notify-send --urgency=low .... >> /tmp/debug_my_udev 2>&1
date +"doner: %c" >> /tmp/debug_my_udev
to figure what runs when and takes how long and prints what output - and also how often this is invoked (eg. if you've cyclic events or so)
Online
No xrandr isn't causing the delay (I used your recommendation to test it to be sure), I think udev is taking a while to process the rule and call hotplug.sh. I want to say notify-send is inconsequential...I don't see how it affects udev's ability or speed of detection and rules processing.
Offline
RUN+= is the wrong approach.
This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device.
Use ENV{SYSTEMD_WANTS}==
Offline
My understanding from his hlast post though is that it takes some time until the script is invoked at all (and neither call here would be long running) - so it's most likely another rule that blocks the processing.
Online
jasonwryan that seemed to have worked for me; thank you! But, like seth, I wouldn't have thought xrandr would've been outside of a 'very short-running foreground task.'
Offline
It's a bash script; there is nothing "short running" about it...
Offline
Despite the bashing™, I'd still check whether you've another rule that actually blocks stuff, esp. not if the script is already invoked late - according to "time xrandr", it lasts few ms here (and few ms more if "bash -c'd")
Online
Yeah I only had one other unrelated rule
Offline