<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Resolution max problem since kernel 4.13" href="https://bugs.freedesktop.org/show_bug.cgi?id=104292#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Resolution max problem since kernel 4.13" href="https://bugs.freedesktop.org/show_bug.cgi?id=104292">bug 104292</a> from <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>There are link training failures. The old code just ploughed on without caring about them, but the current code will try to reduce the link rate/lane count and retry the modeset. This will reduce the overall bandwidth available and we start to drop modes from the list. It appears you have one of those magical devices that happen to work despite them telling us that the link couldn't be trained. Figuring out why the link training fails would be the best approach here. That said, the way we pick the link params vs. the way we reduce them results in a rather strange sequence of events. We start by using the 1080p mode, then we fall back to 1080i, then we go back to 1080p again, then 1080i, and finally we drop the the 1152x720. And in the end even the final attempt at link training at 1.62 ghz with 1 lane fails. Makes for confusing logs if nothing else.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>