Hi Dmitry, On Mon, 15 Sept 2025 at 02:57, Dmitry Baryshkov <dmitry.barysh...@oss.qualcomm.com> wrote: > On Thu, Sep 11, 2025 at 08:15:48PM +0300, Marius Vlad wrote: > > On Thu, Sep 11, 2025 at 04:50:59PM +0300, Dmitry Baryshkov wrote: > > > It's unclear, who should be combining this data: should it be the kernel > > > or the userspace. > > > > Userspace. I've went a bit into why that is in the cover letter. That > > was a pain point in the previous versions raised by other folks. Drivers > > are free to advertise whatever color formats their HW supports. To > > filter what panel/display supports userspace would look at the EDID and do > > an > > intersection with the ones with the driver. This not uncommon, userspace > > already looks today at the EDID for color management / HDR purposes. There's > > just too much for the kernel to handle and rather than offloading that > > to the kernel, people suggested previously to let userspace handle that. > > > > > From my POV deferring this to the userspace doesn't make sense: there > > > will be different quirks for monitors / panels, e.g. the EDID wrongly > > > advertising YUV or not advertising a knowlingly-working capability. > > > > Yeah, for sure. There have been some folks also raising that and discussing > > that a bit further in previous thread on similar topic: > > https://lore.kernel.org/dri-devel/ty4pr01mb14432b688209b2aa416a9522898...@ty4pr01mb14432.jpnprd01.prod.outlook.com/ > > > > Note that people have added quirks into libdisplay-info library to > > overcome these limitations. It is far more easier to that into a library > > than in the kernel. > > This forces everybody who wishes to use this property to use that > library (or to duplicate the code, making it spread over different > projects).
This really is already the case though. There is far more than the kernel can parse and handle in connector modes - and far more than it makes sense for the kernel to do. The kernel absolutely should have enough to support simple usecases, e.g. console and splash screen, to make sure that they work out of the box no matter what. But once you get into HDR/YUV/VRR/stereo/etc usecases, it doesn't make sense for the kernel to abstract the EDID parsing so much that userspace never needs to touch it - it makes the kernel just a lossy middle barrier. So if you look just at compositors, all the big four of KWin, Mutter, Weston, and wlroots, all use libdisplay-info to parse the EDID. And that's fine - they also use libevdev and libinput to handle raw input data, and libxkbcommon to deal with the pain that is keyboards. > > > 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). > > > 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. Cheers, Daniel
