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? 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
Attachment:
pgpAwusPMyg3B.pgp
Description: OpenPGP digital signature
