On Tue, 16 Sept 2025 at 14:11, Daniel Stone <dan...@fooishbar.org> wrote: > > 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?
Yes. I'm sorry if I was not explicit enough. I'm fine with the idea of the color format property (not just for HDMI, DP will need it too). But I think the kernel should not be exposing 4:2:0 there if it detects that the monitor can't support 4:2:0 at all. Likewise we should be failing to enable 4:2:0 for a particular mode if the display didn't list it in Y420CMDB (and we don't have e.g. a quirk of 'the display lies, 420 is supported for this mode). -- With best wishes Dmitry
