On Tue, 16 Sept 2025 at 11:57, Dmitry Baryshkov <dmitry.barysh...@oss.qualcomm.com> wrote: > On Tue, Sep 16, 2025 at 11:48:39AM +0100, Daniel Stone wrote: > > So yeah, I see it as the same as the input situation: you _can_ do the > > basics with raw evdev, but unless you're very special, you should use > > libinput. Equally for output, when you go past what e.g. Plymouth > > would require, use libdisplay-info to parse the EDID, rather than > > trying to make the kernel try to turn the unhinged madness of EDID > > into something userspace can reason about. > > We do a lot of EDID parsing in the kernel, including HDMI VSDB and > Y420CMDB parsing. Do we need anything else for this feature?
I'm slightly confused as to what you're saying here. Are you saying that it's OK for the kernel to expose connector properties for userspace to see which colour properties (model/range/depth/subsampling) are OK and control what is actually used, but your hard line is that the kernel must do an intersection between the sink EDID and the encoder/connector capabilities to filter the list to what it believes to be achievable? Cheers, Daniel
