On Mon, Sep 15, 2025 at 12:33:08PM +0200, Daniel Stone wrote: > > > > I think that the property should reflect the kernel view on the possible > > > > formats, which should be updated during get_modes() (or every time EDID > > > > is being read). > > > > > > The property advertises the supported color formats by display driver. > > > Userspace just filters these out based on what the sink supports. This > > > could just a policy in the compositor / UI. There's nothing preventing > > > you to force push from those advertised formats. > > > > What is the expected behaviour if userspace asks for the colorspace > > which is supported by the driver but not by the display? > > 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. > > > > And that's not to mention that there are enough use-cases where the > > > > connector doesn't have EDID at all. > > > Totally. But what would be the expectation in that case? Drivers can > > > still advertise 'Auto' if they'd like. > > > > 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". 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. Maxime
signature.asc
Description: PGP signature
