mdctl edid
Print what one display says about itself.
mdctl edid <reference> Arguments
| Argument | Type | Required | Meaning |
|---|---|---|---|
| reference | string | Yes | The display, spelled the way `displays` prints it. |
What it prints
One field per line: the display, where the answer came from, and the identity fields the display declares.
What one display says about itself: manufacturer, product, serial, when it was made, and its native size.
mdctl edid physical:A1B2C3D4-5E6F-4071-8293-A4B5C6D7E8F9
display physical:A1B2C3D4-5E6F-4071-8293-A4B5C6D7E8F9
source the panel's own EDID, as macOS decoded it
name Studio Display
vendor APP (1552)
model 41005
serial 1234567
made week 33, 2022
native 5120x2880 It is not the EDID block, and it does not pretend to be
Apple silicon publishes no raw EDID: IODisplayEDID is simply absent from the registry. What it
does publish is DisplayAttributes, the same information already decoded. That is the whole of
what a read back can honestly be here, and it is the useful half, because nobody reads a hex block
to work out which monitor they are looking at.
The source line is the point, not a footnote
“What the panel says” and “what this app wrote when it made the display” are different claims, and a report that blurs them is worse than no report. The second line always says which one you are looking at.
mdctl edid virtual:4C2E9A31-7F0B-4E58-9C1D-8A0F2B6D5E77
display virtual:4C2E9A31-7F0B-4E58-9C1D-8A0F2B6D5E77
source what MoreDisplays wrote when it created this display
name Home ultrawide
vendor MD (19780)
model 1
native 5120x1440 Exit codes
The same four across every command, so a script can branch on the number without knowing which command produced it.
| Code | Name | When |
|---|---|---|
| 0 | ok | The command succeeded. |
| 1 | commandFailed | The app understood the command and refused or failed it. The reason is on stderr. |
| 2 | usage | The arguments were wrong. Nothing was sent. |
| 3 | appNotRunning | No app is listening on the socket. |