On Thu, 2 Jun 2022 19:40:01 +0300
Ville Syrjälä <ville.syrjala@linux.intel.com> 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@linux.intel.com> 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?

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 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". People can point fingers at Plymouth, but I
would imagine the actual fixes will come as patches to other KMS clients
and not Plymouth.


Thanks,
pq