Linux Command Line: Get the Details of your Monitor

I've spent a fair bit of time working out how to find out hardware details of a Linux computer using the command line. While I now know how to get most of those details from a Linux OS with scripts, I'd recommend installing and using inxi. It's described like this by Debian's package system: "Inxi is a system information script that can display various things about your hardware and software ..." There are other similar products that do this with a GUI interface, but I still prefer the command line. For all that, the single hardest thing to discover about your system is what kind of monitor you have attached. Not what the resolution is: that's not too hard, inxi can tell you:

$ inxi -xx -G
  Device-1: bcm2711-vc5 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:gpu
  Device-2: bcm2711-hdmi0 driver: N/A bus ID: N/A chip ID: brcm:soc
  Device-3: bcm2711-hdmi1 driver: N/A bus ID: N/A chip ID: brcm:soc
  Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting
  unloaded: fbdev resolution: 1050x1680~60Hz s-dpi: 96
  OpenGL: renderer: V3D 4.2 v: 2.1 Mesa 20.3.5 direct render: Yes

This is on a Raspberry Pi with an old Acer monitor attached.

The "correct" way to get monitor information is using EDID ("Extended Display Identification Data") - essentially a small block of metadata stored in a binary format on the monitor itself. From the README for the "monitor-edid" package:

EDID (Extended Display Identification Data) is a VESA standard data
format that contains information about a monitor and its capabilities.

The information is stored in the monitor and is used to communicate
with the system through a Display Data Channel (DDC), which sites
between the monitor and the PC graphics adapter.

Both Fedora and Debian have ways of accessing and interpreting the EDID data, but unusually they appear to be entirely unrelated (normally utility programs on both are essentially the same and built from the same sources) and one works and the other appears not to. Let's look at Fedora first.

After searching the package repository for anything with "edid" in the name, the "monitor-edid" package seemed the likeliest. I installed it. The documentation borders on non-existent (a README that gives a useful statement about EDIDs but not about the programs it contains, and no man pages) so I ended up guessing how to use it. And got lucky: all the systems I'd read about have two programs, one to pull the EDID information from the monitor and one to interpret it.

# monitor-get-edid | monitor-parse-edid
Name: DELL U3011
EDID version: 1.4
EDID extension blocks: 1
Screen size: 64.1 cm x 40.1 cm (29.77 inches, aspect ratio 16/10 = 1.60)
Gamma: 2.2
Digital signal
Max video bandwidth: 280 MHz

This was followed by a bunch of technical details and ModeLines that would have been useful with setting up X two decades ago, but generally aren't needed anymore because it's all handled so transparently by the OS now. But the main point is: I have my monitor maker and model number.

Can we do the same thing on Debian? The most commonly mentioned solution when I searched for how to get EDID information was to run get-edid | parse-edid and the "read-edid" package provides both these executables.

EDID is, as mentioned, a binary format. So if you succeed in getting it - by running monitor-get-edid (on Fedora) or get-edid (on Debian) it will just barf some unreadable junk on your screen. This is why it's usually immediately piped into a parser (or dumped to a file). But on Debian ("regular" amd64 flavour and Raspberry Pi OS), get-edid puts out about 40 lines of text, all of which could be summarised by the second-last line which says "I'm sorry nothing was successful. Maybe try some other arguments." If you read the docs ... there's not really anything else to try.

I kept searching the web until I found a reference to using the command xrandr --props - the output of which appears to include a hex-encoded version of the EDID (even on Debian systems). Except ... I couldn't figure out how to decode or parse it (others probably can - I couldn't). What I eventually found instead was the /sys/devices/pci0000:00/ tree. From there, run:

$ cd /sys/devices/pci0000:00/
$ find . -name '*edid*' -exec ls -l {} \;
-r--r--r-- 1 root root 0 Sep  5 10:06 ./0000:00:02.0/drm/card0/card0-HDMI-A-1/edid
-r--r--r-- 1 root root 0 Jan  8 20:00 ./0000:00:02.0/drm/card0/card0-HDMI-A-2/edid
-r--r--r-- 1 root root 0 Jan  8 20:00 ./0000:00:02.0/drm/card0/card0-DP-1/edid

Unfortunately because these are system files rather than standard files, we can't tell which ones actually contain data (all of them claim to have a size of "0"). So I used cat to dump each one, and found out that only the first actually contained anything.

$ cat ./0000:00:02.0/drm/card0/card0-HDMI-A-1/edid | parse-edid
Checksum Correct

Section "Monitor"
    Identifier "SyncMaster"
    ModelName "SyncMaster"
    VendorName "SAM"
    # Monitor Manufactured week 44 of 2009
    # EDID version 1.3
    # Digital Display
    DisplaySize 510 290
    Gamma 2.20
    Option "DPMS" "true"
    Horizsync 30-81
    VertRefresh 56-60

What I find interesting here is that I got only a partial vendor name ("SAM" - you can probably guess) and a partial, nearly useless, model name. Samsung made a lot of SyncMaster monitors in different sizes and capabilities.

On a Raspberry Pi I did a wider search because I was even less sure of the location:

$ cd /sys/devices
$ find . -iname "*hdmi*" -print
$ cat /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid | parse-edid
Checksum Correct

Section "Monitor"
    Identifier "Acer AL2216W"
    ModelName "Acer AL2216W"
    VendorName "ACR"
    # Monitor Manufactured week 20 of 2007

This time we got full identification of the monitor. (I suspect if the Pi had two monitors attached, we would have found a second file as well, but I haven't tried this.)

Because this discovery process varies so much by platform, I've pretty much given up on the idea of automating it in a single script that would tell me what monitor is attached to the current host. In fact, this is so hard that I'm considering getting out of my chair and walking around the back of the monitor to read the name plate. While that's obviously a viable method too, getting the answer programmatically is useful if it can be automated - and particularly useful if you're doing a remote inventory. Debian has been my preferred for many years, this is very disappointing.