<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - link retraining for DP not possible with current design of Atomic modeset framework" href="https://bugs.freedesktop.org/show_bug.cgi?id=91871#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - link retraining for DP not possible with current design of Atomic modeset framework" href="https://bugs.freedesktop.org/show_bug.cgi?id=91871">bug 91871</a> from <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>One potential idea came to mind recently; We could try to train the link to the max immediately upon long hpd, and based on the maximum rate that was achieved we could filter out modes that exceed it. That way userspace shouldn't be able to request anything we can't deliver. Unfortunately there are at least two problems with that apporach. First one being fastboot. We can't try to train the link when taking over from the BIOS without blinking the display, so we would either have to do that or limit the modes to whatever bitrate the BIOS chose to use. The other problem being that even if we initially succeed in training the link at a certain bitrate, there's no guarantee we can repeat the same feat later eg. due to changing environmental conditions. Though maybe this latter worry is a bit more theoretical, not sure.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>