On Mon, 15 Sept 2025 at 11:46, Dmitry Baryshkov <dmitry.barysh...@oss.qualcomm.com> wrote: > On Mon, Sep 15, 2025 at 12:33:08PM +0200, Daniel Stone wrote: > > 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.
It's not super complicated if you just want to get a splash screen up, and you're willing to be conservative about the way in which you do it to get _something_ up on screen. Or if you're on a laptop so you'd rather not have your HDMI clock smashed up to max all the time. But yeah, as soon as you get to CM and HDR usecases, userspace really wants to have both control and visibility here. The cable usecase is a very real one - you want to use the most conservative setting possible to make sure you get _something_ on screen. But then the CM usecase is a very real one too - you want to get the best image possible on screen rather than destroying accuracy, even at the cost of the dreaded 'Can you see this now you've changed your display settings? [Y] [N, timeout 20sec]' dialog box. So yeah, i'm not really seeing any way around giving userspace explicit visibility and control here - the kernel can't 'just do the right thing' in all cases, and creating new uAPI to abstract EDID seems the wrong direction as a) there's already a perfectly good uAPI for EDID, and b) it means the kernel has to do a lot of complex interpretation and transformation-of-representation of information it won't even do anything with. Cheers, Daniel
