<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - HP Dreamcolor display *Error* No EDID read"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110371#c10">Comment # 10</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - HP Dreamcolor display *Error* No EDID read"
href="https://bugs.freedesktop.org/show_bug.cgi?id=110371">bug 110371</a>
from <span class="vcard"><a class="email" href="mailto:Babblebones@gmail.com" title="Babblebones@gmail.com">Babblebones@gmail.com</a>
</span></b>
<pre>Best I can tell, and I may be wrong, the error checking code was moved from the
DC part straight into DRM which now replicates the exact bug which was reverted
by the above DC commits but were never implemented for DRM.
<a href="https://www.st.com/en/touch-and-display-controllers/stdp8028.html">https://www.st.com/en/touch-and-display-controllers/stdp8028.html</a>
My dreamcolor display uses a STDP8028 chip, istting inbetween the display and
the motherboard just behind the screen, to convert a displayport signal coming
off the board into a dual channel LVDS to run the display.
<a href="https://www.st.com/en/touch-and-display-controllers/stdp8028.html">https://www.st.com/en/touch-and-display-controllers/stdp8028.html</a>
The EDID can't be read through this for some reason and it doesn't print any
modelines at all for the display so it picks the lowest resolution possible and
all the timings are incorrect resulting in the display scramble.
I hope the behavior highlighted in the above commit can help someone search for
the regression in the new DRM mode setting as it produces the exact same type
of scramble and lack of modelines.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>