monitor loses DVI after KMS / EDID issue?
marius at gedmin.as
Wed May 29 11:14:25 UTC 2019
On Sat, May 25, 2019 at 06:56:54PM -0600, Benjamin Slade wrote:
> How do I determine what the appropriate EDID should be?
The kernel exposes the EDID block of connected monitors at
You can feed that to edid-decode and see if it makes sense, e.g. is the
manufacturer string right? Does it show the video modes you expect?
(Maybe you can plug in the monitor through your HDMI-to-VGA contraption
and get the EDID that way? I've no idea if that'll pass through the
monitors EDID, or if you'll get some synthetic data block from the
digital-to-analog converter chip. I've no idea how HDMI-to-VGA adapters
work. Are there HDMI-to-DVI cables you could try?)
> And how do I go about loading it into RAM after boot?
This is painful, especially the part where you maybe have to bake the
EDID file into your initramfs under certain underspecified circumstances:
(Note: you need the binary EDID file, not the decoded output you get
from edid-decode, or the hex-encoded string you get from xrandr --props.)
The part where you specify the EDID filename on the kernel command line
is also fun -- it means a reboot for every test. Eh.
(It's also The Future, because Wayland compositors don't generally allow
you to override monitor sync ranges or provide custom mode timings, so
all the hardware workarounds have to be done via a custom EDID.)
TCP_UP - The 16-bit TCP Urgent Pointer, encoded as the hex
representation of the value of the field. The hex string MUST be
capitalized since it is urgent.
-- RFC 3093
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the xorg