Hi,
On Wed, May 11, 2022 at 2:32 PM Doug Anderson dianders@chromium.org wrote:
Hi,
On Wed, May 11, 2022 at 12:14 AM Thomas Zimmermann tzimmermann@suse.de 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/d...
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.I31ec454f8d4ffce51a7708a8092f8...
-Doug