On Tue, Sep 16, 2025 at 12:35:50PM +0100, Daniel Stone wrote: > Hi, > > On Tue, 16 Sept 2025 at 12:15, Dmitry Baryshkov > <[email protected]> wrote: > > On Tue, 16 Sept 2025 at 14:11, Daniel Stone <[email protected]> wrote: > > > 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). > > No problem at all, I think I was just being dense and not quite > parsing it properly. :) > > I can see where you're going. There's definitely quite a bit of sense > in it - I'm just not sure about the value tradeoff, since I would > expect any userspace which is sophisticated enough to want > fine-grained control (as opposed to 'just get the splash screen up so > the user can enter their LUKS passphrase'), to be sophisticated enough > to also be parsing the EDID.
That's fine. > So I would still lean towards it not being worth the complexity in the > kernel to implement validation for userspace which really should know > better - and which already needs to have fallback handling for silent > as well as explicit failure, given part of the usecase is to be able > to deal with marginal signal propagation. But I'm not really against > it, so if you really want to see it then that should be fine. Well... I really think that we should not be exporting the values that are going to fail. In the end it's as easy as checking what was parsed from the HDMI VSDB and Y420CMDB. Moreover, those checks would also fit nicely into the hdmi_compute_config() / hdmi_compute_format() (a part of drm_atomic_helper_connector_hdmi_check()). -- With best wishes Dmitry
