On Fri, Jun 03, 2022 at 10:19:09AM +0300, Pekka Paalanen wrote: > On Thu, 2 Jun 2022 19:40:01 +0300 > Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > > On Thu, Jun 02, 2022 at 10:47:59AM +0300, Pekka Paalanen wrote: > > > On Wed, 1 Jun 2022 17:06:25 +0300 > > > Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > > > > > ... > > > > > The "Colorspace" property just changes what we report to the display > > > > via infoframes/MSA/SDP. It does not cause the display hardware to do > > > > any colorspace conversion/etc. > > > > > > Good. > > > > > > > To actually force the display hardware to do the desired conversion > > > > we need some new properties. ATM the only automagic conversion that > > > > can happen (at least with i915) is the RGB 4:4:4->YCbCr 4:2:0 fallback, > > > > which is needed on some displays to get 4k+ modes to work at all. > > > > > > When "Colorspace" says RGB, and the automatic fallback would kick in to > > > create a conflict, what happens? > > > > I would put that in the "Doctor, it hurts when I..." category. > > Hi Ville, > > I meant specifically the case where the driver chooses to use YCbCr > 4:2:0 even though userspace is setting absolutely everything to RGB. > > So yeah, that is a problem, like you and Sebastian agreed later. > > Am I safe from that automatic driver fallback if I don't use 4k or > bigger video modes? What about e.g. 1080p@120 or something? Can I > calculate when the fallback will happen and choose my "Colorspace" > accordingly? Which also requires me to set up the RGB->YCbCR color > model conversion myself? Porbably not something you can trivially compute unless you replicate the exact logic from the driver. > > What about failing the modeset instead if userspace sets "Colorspace" > explicitly to RGB, and the driver would need to fall back to YCbCR > 4:2:0? > > That would make the most sense to me, as then the driver would not > silently do a buggy thing. I'm not sure there's much point in polishing that turd too much. Should just add the explicit props and make userspace that actually cares about color management set them exactly as it likes. > > > I thought we agreed that "max bpc" means limiting link bpc to at most > > > that value, but the driver will automatically pick a lower value if > > > that makes the requested video mode work (and in lack of new KMS > > > properties). > > > > > > I have no desire that change that. I also think the Plymouth issue is > > > not fully fixable without some new KMS property, and until then the > > > only thing Plymouth could do is to smash "max bpc" always to 8 - which > > > mostly stops being a problem once display servers learn to handle "max > > > bpc". > > > > There's no real differene between the kernel automagically clamping > > "max bpc" to the current BIOS programmed value vs. plymouth doing it. > > Either approach will break deep color support for current userspace > > which doesn't reset "max bpc" back to the max. > > There is one big difference: if Plymouth does it, then people cannot > scream "kernel regression". But they'll just report the bugs against i915 anyway. I'd rather not have to deal with those without at least being able to point them at an existing fix, at least for the more common wayland compositors+Xorg. > People can point fingers at Plymouth, but I > would imagine the actual fixes will come as patches to other KMS clients > and not Plymouth. I'm worried that we'll be stuck herding these bug reports for quite some time. -- Ville Syrjälä Intel
