Detecting monitors on machine over local ssh connection

Question

I need to write a script to check on video related things on machines in the local network, e.g.

• Is a monitor plugged in?
• Are the video drivers up to date and appropriate for the hardware?
• Is Xorg running?

However I am having trouble finding a reliable way of telling if a monitor is plugged in across a local ssh connection. For instance, if I ssh from machine A into another machine B that's on the same subnet, the xrandr tool returns information about the monitor plugged into machine A instead of machine B. I have tried a number of other tools, but all give the same effect. How can I be sure that I'm probing the monitor plugged to the machine that I'm connected to rather than the machine where I'm running the shell session?

Solution 1

Disable X11 forwarding (using -x switch to ssh) and set the DISPLAY environment variable for machine B. For example, this will tell you the settings for :0 on machine B:

ssh -x machineB
DISPLAY=:0 xrandr

Solution 2

A tool named "get-edid" allow you to read the identification information from the monitor read-edid website Extended display identification data

and "parse-edid" create from get-edid, the correct X config monitor section:

example on my machine:

# get-edid | parse-edid 
parse-edid: parse-edid version 2.0.0
get-edid: get-edid version 2.0.0

Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful

VBE version 300
VBE string at 0xc01f0 "ATI ATOMBIOS"

VBE/DDC service about to be called
Report DDC capabilities

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful

Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination supports DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
Read EDID

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call successful

parse-edid: EDID checksum passed.

# EDID version 1 revision 3
Section "Monitor"
# Block type: 2:0 3:fd
# Block type: 2:0 3:fc
Identifier "Acer H233H"
VendorName "ACR"
ModelName "Acer H233H"
# Block type: 2:0 3:fd
HorizSync 30-83
VertRefresh 56-75
# Max dot clock (video bandwidth) 170 MHz
# Block type: 2:0 3:fc
# Block type: 2:0 3:ff
# DPMS capabilities: Active off:yes  Suspend:no  Standby:no

Mode    "1920x1080" # vfreq 60.000Hz, hfreq 67.500kHz
    DotClock    148.500000
    HTimings    1920 2008 2052 2200
    VTimings    1080 1084 1089 1125
    Flags   "+HSync" "+VSync"
EndMode
# Block type: 2:0 3:fd
# Block type: 2:0 3:fc
# Block type: 2:0 3:ff
EndSection

You must be root to use them. Nothing is written in /etc/X11/xorg.conf

Comments

[jayhendren]

thanks, that solved most of my problems. Now if I could get X to dump the information that I need, that would be perfect.

[depquid]

A combination of the X logs and lspci -vv could provide a lot of info about drivers and hardware. Feel free to open a new question if you need help with more specifics.

[jayhendren]

Thanks. I've been using lspci to find manufacturers of hardware and determine what drivers they require, but the X logs (I'm looking at /var/log/Xorg.0.log) are a little more difficult to parse. For instance, just because there's errors in the log file doesn't necessarily mean that X failed to start properly.

[depquid]

@jayhendren I'd suggest creating a new question: "How do I remotely check that X is running?" Don't forget to include why you need to know this, since in most use cases, the user will provide notice if X fails to start.

[jayhendren]

Shouldn't ps aux | grep Xorg do the trick for that? In my previous comment I was only providing an example of why the Xorg log files aren't easy to parse.

[depquid]

@jayhendren Again, that's a new question (and the answer depends on what you're really trying to accomplish) and shouldn't be in the comments here.