Re: [PATCH v5 0/3] Add "link bpc" DRM property

[Pekka Paalanen]

On Mon, 30 Mar 2026 15:01:33 -0400
Harry Wentland <harry.wentland@xxxxxxx> wrote:

> On 2026-03-26 09:53, Pekka Paalanen wrote:
> > Hi Michel,
> > 
> > I have some opinions as well.
> > 
> > On Tue, 24 Mar 2026 17:44:21 +0100
> > Michel Dänzer <michel.daenzer@xxxxxxxxxxx> wrote:
> >   
> >> Per my previous posts, my concerns are:
> >>
> >> * The meaning of the "link bpc" property value isn't defined well
> >> enough vs things like dithering or DSC, which will likely result in
> >> compositors / users overestimating what value they need / want,
> >> resulting in compositors spuriously rejecting configurations which
> >> would work perfectly fine, and/or spurious issue reports.  
> > 
> > That is ok. Compositors need to understand what the numbers mean, how
> > reliable they are, and act accordingly. Knowing the lower bound for
> > link precision is already useful as it guarantees a minimum precision.
> > It is up to the compositors to decide how they communicate this.
> > 
> > Or course, assuming lossy compression is not too lossy. Maybe
> > lossy compression should be forbidden by default unless explicitly
> > enabled by userspace?
> >   
> 
> I disagree. While technically lossy, DSC is perceptually lossless, at
> least according to the designers of DSC. If I'm not mistaken this is
> all based on extensive studies.
> 
> The decision to enable DSC or not has an impact on the power consumption
> of the HW, in ways that are often nuanced. Userspace has no way to know
> or understand these nuances. This should be in control of the driver.

I guess time will tell.

Are you saying that enabling DSC might have disadvantages aside from
image quality?

> At most I could see a "never do DSC or dither" toggle, if one is really
> concerned about this, but I don't realistically see use-cases where this
> would improve user experience, even for users that care about color work
> and correctness.

I'm not familiar with DSC, so I cannot criticise it. Dithering OTOH
seems to be obviously suspect though.

Temporal dithering - what if your refresh rate is 30 Hz for some movie
playback?

Spatial dithering - what if you have a low-resolution screen?

I would not assume that dithering is always ok, and always achieves its
theoretical results.

> The YCbCr420 case is different. We probably want a way for userspace to
> understand that half 3/4 of chroma values are being tossed out. This
> would be significant for RGB content but insignificant for YCbCr420
> content.

Do you mean full resolution vs. chroma sub-sampled to 2x2 blocks? I
would again not assume "insignificant", because it depends on the
picture content and angular pixel density (can you see individual
pixels at your viewing distance). Gray-scale text will be fine, but
colored text is another question.

I'm fine with proceeding with these assumptions, as long as it is
acknowledged that these assumptions might turn out false later and have
a contingency plan.


Thanks,
pq

Attachment: pgphsErS0QNun.pgp
Description: OpenPGP digital signature