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. 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. Cheers, Daniel
