On Mon, Sep 15, 2025 at 12:33:08PM +0200, Daniel Stone wrote: > 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 understand the HDR part, but what is so special regarding YUV? We already need to parse VSDB information inside the kernel. > > > > 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). Ack > > > > > 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. As I wrote, I completely agree regarding CM and HDR. From my POV the YUV part isn't that complicated. I might be wrong though. -- With best wishes Dmitry
