Is there any event that is triggered when I plug in or out an external monitor into the DisplayPort of my laptop? ACPID and UDEV don't react at all.

I'm using onboard graphics on an intel chip. Here is a similar discussion which is already a couple of years old.

I don't want to use polling but I need to have some configuration that set's the display settings automatically depending on if the display is connected.

  • 4
    It can be done with udev. What is your kernel version? Are you using KMS (kernel mode setting)? – Andy May 25 '11 at 16:00
  • Thanks for the answer. I am not sure about KMS, but as I said in the question, udev doesn't send any events. (udevadm monitor --property does not react at all) – janoliver May 25 '11 at 16:27
  • @Andy: the last time this came up, it seemed that most systems required polling. If you've found a way to trigger a udev event, could you answer that question? – Gilles 'SO- stop being evil' May 25 '11 at 23:03
  • 1
    I finally got it running loading i915 as kernel module. – janoliver May 29 '11 at 12:13
  • 3
    You can use xrandr or disper to detect if external monitor has been plugged in. github.com/wertarbyte/autorandr can show you how to use them. But xrandr/disper might not supported your video card. – number5 Dec 5 '11 at 10:33

NOTE: This was tested on a laptop with a i915 driven graphics card.


NOTE: When a new screen is plugged in, no event is sent to the host, this stayed true even after my last edit. So the only way is to use polling. Trying to make them as effiicient as possible...


Finally there's one better solution (through ACPI):

There's still no event, but ACPI seems more efficient than xrandr to inquire. (Nota: This requires ACPI kernel modules loaded, but doesn't require root privileges).

My final solution (using bash):

isVgaConnected() {
    local crtState
    read -a < /proc/acpi/video/VID/CRT0/state crtState
    test $(( ( ${crtState[1]} >>4 ) ${1:+*-1+1} )) -ne 0

Now a test:

$ if isVgaConnected; then echo yes; else echo no; fi 

It's plugged in, so now I unplug it:

$ if isVgaConnected; then echo yes; else echo no; fi 

NOTE: ${1:+*-1+1} permit a boolean argument: If something is present, answer would be inverted: ( crtState >> 4 ) * -1 + 1.

and the final script:


export crtProcEntry=/proc/acpi/video/VID/CRT0/state

isVgaConnected() {
    local crtState
    read -a < $crtProcEntry crtState
    test $(( ( ${crtState[1]} >>4 ) ${1:+*-1+1} )) -ne 0

unset switch
isVgaConnected || switch=not
while :;do
    while isVgaConnected $switch;do
        sleep $delay
    if [ "$switch" ];then
        unset switch
        echo VGA IS connected
        # doing something while VGA is connected
        echo VGA is NOT connected.
        # doing something else, maybe.

WARNINGS: lighter than xrandr, but not unimportant with a delay smaller than 0.02 seconds, the Bash script will go to the top of resource eaters process (top)!

While this costs ~0.001 sec:

$ time read -a </proc/stat crtStat

This requires ~0.030 sec:

$ read -a < /proc/acpi/video/VID/CRT0/state crtState

This is big! So depending on what you need, delay could be reasonably set between 0.5 and 2.


I've finally found something, using this:

Important disclaimer: Playing with /proc and /sys entries could break your system!!! So don't try the following on production systems.

mapfile watchFileList < <(
    find /sys /proc -type f 2>/dev/null |
    grep -i acpi\\\|i91 

prompt=("/" "|" '\' '-');

while :; do
  mapfile watchStat < <(
    grep -H . ${watchFileList[@]} 2>/dev/null

  for ((i=0;i<=${#watchStat[@]};i++)); do
    [ "${watchStat[i]}" == "${oldStat[i]}" ] || echo ${watchStat[i]}

  sleep .5
  printf "\r%s\r" ${prompt[l++]}
  [ $l -eq 4 ]&&l=0

... after some cleaning of unwanted entrys:

for ((i=0;i<=${#watchFileList[@]};i++)); do
  [[ "${watchFileList[$i]}" =~ /sys/firmware/acpi/interrupts/sci ]] &&
      unset watchFileList[$i] && echo $i

I've been able to read this:

/proc/acpi/video/VID/CRT0/state:state: 0x1d
/proc/acpi/video/VID/CRT0/state:state: 0x0d
/proc/acpi/video/VID/CRT0/state:state: 0x1d

When I plug, unplug, and replug in monitor cable.

Original Answer

When the config is inquired (running system/preferences/monitor or xrandr), graphics cards do a type of scan, so running xrandr -q give you the info, but you have to poll the status.

I've scanned all logs, (kernel, daemon, X and so forth) searching through /proc & /sys, and clearly nothing seems to exist that satisfies your request.

I've tried this too:

export spc50="$(printf "%50s" "")"
watch -n1  '
    find /proc/acpi/video -type f |
        xargs grep -H . |
        sed "s/^\([^:]*):/\1'$spc50'}:/;
             s/^\(.\{50\}\) *:/\1 /"'

After all that, if you run System/Preferences/Monitor while no new screen has just been plugged in, nor unplugged, the tool will appear simply (normally). But if you've plugged or unplugged a screen before, at times you'll run this tool and you'll see your desktop make a type of reset or refresh (same if you run xrandr).

This seems to confirm that this tool asks for xrandr (or works in the same manner) by polling status periodically, starting at the time it's run.

You could try yourself:

$ for ((i=10;i--;)); do xrandr -q | grep ' connected' | wc -l; sleep 1; done

This will display how many screens (displays) are connected, for 10 seconds.

While this runs, plug and/or unplug your screen/monitor and look what's happens. So you could create a little Bash test function:

isVgaConnected() {
    local xRandr=$(xrandr -q)
    [ "$xRandr" == "${xRandr#*VGA1 con}" ] || return 0
    return 1

which would be useable as in:

$ if isVgaConnected; then echo yes; fi

But be careful, xrandr takes about 0.140 sec to 0.200 sec while no change happens on plugs and up to 0.700 seconds whenever something was plugged or unplugged just before (NOTE: It seems not to be a resource eater).


To ensure I'm not teaching something incorrect, I've searched around the Web and docs, but didn't find anything about DBus and Screens.

Finally, I've run in two different windows dbus-monitor --system (I've been playing with options too) and the little script I wrote:

$ for ((i=1000;i--;)); do isVgaConnected && echo yes || echo no; sleep .5; done

... and again plugged, than unplugged the monitor, many times. So now I could say:

  • In this configuration, using i915 driver, there is no other way than running xrandr -q to know if a monitor is plugged in or not.

But use caution, because there doesn't appear to be other ways. For instance, xrandr seems to share this info, so my GNOME desktop would switch to xinerama automatically... when I ran xrandr.

Some docs


The following lines appeared in udevadm monitor

KERNEL[46578.184280] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [46578.195887] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)

when attaching a monitor to the VGA-Connector. So there might be a way to figure this out.

  • With an nVidia 9800 GT and proprietary drivers, udevadm monitor shows nothing when I connect an HDMI monitor. What hardware/drivers are you using? – frankster Sep 8 '14 at 8:30
  • Pityingly, that does not work reliable for me. Sometimes I get these event messages when I plug-in my monitor and sometimes not. – Tobias Jul 7 '17 at 4:24

For those who, for whatever reason, don't want to take the hotplug route, it is still possible to not poll within a script using inotifywait:



renice +19 $$ >/dev/null



while [ 1 ]; do
    DUAL=$(cat /sys/class/drm/card0-DP-2/status)

    if [ "$OLD_DUAL" != "$DUAL" ]; then
        if [ "$DUAL" == "connected" ]; then
            echo 'Dual monitor setup'
            xrandr --output $SCREEN_LEFT --auto --rotate normal --pos 0x0 --output $SCREEN_RIGHT --auto --rotate normal --below $SCREEN_LEFT
            echo 'Single monitor setup'
            xrandr --auto


    inotifywait -q -e close /sys/class/drm/card0-DP-2/status >/dev/null

It is best invoked from your .xsessionrc, not forgetting the ending &. Polling with xrandr gave serious usability issues on my brand new laptop (mouse would stall periodically).

  • I wouldn't have thought that you can use inotify on /proc and just doing inotifywait -q -e close /sys/class/drm/card0-DP-2/status indeed did not end upon disconnecting DP-2 on my system – nhed Jan 16 '18 at 23:42

I stuck to using srandrd. It monitors X events and triggers your script when a display gets connected or disconnected.


Obviously there should be something! :) /sys filesystem tells userspace what hardware is available, so userspace tools (such as udev or mdev) can dynamically populate a "/dev" directory with device nodes representing the currently available hardware. Linux provides two hotplug interfaces: /sbin/hotplug and netlink.

There is a small C demo in the following file. http://www.kernel.org/doc/pending/hotplug.txt


Mostly system/application software on Linux today used some ipc techniques for communicating with each other. D-Bus is now mostly used with GNOME applications, and might help.

Linux Journal:

D-BUS can facilitate sending events, or signals, through the system, allowing different components in the system to communicate and ultimately to integrate better. For example, a Bluetooth dæmon can send an incoming call signal that your music player can intercept, muting the volume until the call ends.


D-Bus supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a per-user-login-session daemon (for general inter-process communication needs among user applications)

There is even a Python library for this, and ubuntu recently used this ability which called "zeitgeist".


Graphically you can see if the monitor is recognized with Monitor, I know that you can find this on Ubuntu, Fedora and others in this(or a similar) location.


And you can turn-on/off any monitor you want or use both at same time with duplicate image in both monitor or independent monitors

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.