Hi, On Tue, 16 Sept 2025 at 09:29, Maxime Ripard <mrip...@kernel.org> wrote: > On Mon, Sep 15, 2025 at 12:33:08PM +0200, Daniel Stone wrote: > > Quite possibly just a failure to display. Same as if the driver > > guesses it wrong - including for reasons it can never statically > > detect (e.g. buying a 10m-long uncertified HDMI cable which drops > > signal, or having the cable pulled around a 90° bend making it very > > marginal for transmission). > > I guess there's two cases for "not supported by the display"? > > If the display reports that it supports a format but is broken, yeah, > there's not much we can do except maybe add a quirk. > > But if it's that the monitor doesn't support that format in the first > place, we should just reject that commit. > > Just like we don't let any mode go through if we know it's obviously > wrong (like if it exceeds max_tmds_clock) but can't indeed account for a > long / broken cable. > > > > I'm trying to point out that this complicates userspace: it is now > > > required to handle EDID and non-EDID cases for no practical reason. For > > > all other usecases it is enough to query available modes from the > > > kernel. > > > > But not 'now', because that's been happening for years. And not 'no > > practical reason', because in order to support features the kernel has > > no involvement in (colour management and HDR as a large part), you > > need to see the full EDID. > > I guess it's still slightly different when we're talking about opt-in > features like VRR or HDR, and "just get something on my screen".
Yeah, I absolutely agree (as with the quoted parts as well) - the kernel should absolutely just get stuff on the screen. > Introducing a dependency on libdisplay-info for the latter is still > something new, but I guess you can always YOLO it, try a format and see > if it works. Again though, it's not something new. I promise you that Weston (for over a year), Mutter (for about a year), KWin (for over two years), and wlroots (for two and a half years) already have hard deps on libdisplay-info. Even outside of 'serious' compositors, Mesa requires it to support HDR in VK_KHR_display (when it was added a couple of months ago), Cheers, Daniel
