Comment # 10
on bug 110371
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 reverted 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 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. 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 type of scramble and lack of modelines.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
