From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 110371] HP Dreamcolor display *Error* No EDID read Date: Fri, 10 May 2019 22:32:13 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1473255004==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 708FB6E7BE for ; Fri, 10 May 2019 22:32:13 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1473255004== Content-Type: multipart/alternative; boundary="15575275332.D96C.10457" Content-Transfer-Encoding: 7bit --15575275332.D96C.10457 Date: Fri, 10 May 2019 22:32:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D110371 --- Comment #10 from Babblebones@gmail.com --- 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 reve= rted by the above DC commits but were never implemented for DRM. https://www.st.com/en/touch-and-display-controllers/stdp8028.html My dreamcolor display uses a STDP8028 chip, istting inbetween the display a= nd the motherboard just behind the screen, to convert a displayport signal com= ing off the board into a dual channel LVDS to run the display. https://www.st.com/en/touch-and-display-controllers/stdp8028.html 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 ty= pe of scramble and lack of modelines. --=20 You are receiving this mail because: You are the assignee for the bug.= --15575275332.D96C.10457 Date: Fri, 10 May 2019 22:32:13 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 10 on bug 11037= 1 from Babblebones&= #64;gmail.com 
Best I can tell, and I may be wrong, the error checking code w=
as moved from the
DC part straight into DRM which now replicates the exact bug which was reve=
rted
by the above DC commits but were never implemented for DRM.

https://www.st.com/en/touch-and-display-controllers/stdp8028.html

My dreamcolor display uses a STDP8028 chip, istting inbetween the display a=
nd
the motherboard just behind the screen, to convert a displayport signal com=
ing
off the board into a dual channel LVDS to run the display.

https://www.st.com/en/touch-and-display-controllers/stdp8028.html

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 ty=
pe
of scramble and lack of modelines.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15575275332.D96C.10457-- --===============1473255004== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1473255004==--