Hi, On Wed, May 11, 2022 at 2:32 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Wed, May 11, 2022 at 12:14 AM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > > > Hi > > > > Am 10.05.22 um 22:51 schrieb Douglas Anderson: > > > If we're unable to read the EDID for a display because it's corrupt / > > > bogus / invalid then we'll add a set of standard modes for the > > > display. When userspace looks at these modes it doesn't really have a > > > good concept for which mode to pick and it'll likely pick the highest > > > resolution one by default. That's probably not ideal because the modes > > > were purely guesses on the part of the Linux kernel. > > > > I'm skeptical. Why does the kernel do a better job than userspace here? > > Only the graphics driver could possibly make such a decision. > > > > Not setting any preferred mode at least gives a clear message to userspace. > > OK, that's a fair point. So I tried to find out what our userspace is > doing. I believe it's: > > https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/drm/common/drm_util.cc;l=529 > > Specifically this bit of code: > > // If we still have no preferred mode, then use the first one since it should > // be the best mode. > if (!*out_native_mode && !modes.empty()) > *out_native_mode = modes.front().get(); > > Do you agree with what our userspace is doing here, or is it wrong? > > If our userspace is doing the right thing, then I guess the problem is > the call to "drm_mode_sort(&connector->modes);" at the end of > drm_helper_probe_single_connector_modes(). Would you be OK with me > _not_ sorting the modes in the "bad EDID" case? That also seems to fix > my problem... I've implemented the "don't mark preferred, but don't sort" as a v3. Hopefully it looks good. https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid -Doug
