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

[Harry Wentland]

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.

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.

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.

Harry

>> With my compositor developer hat on, what I'd want to know is
>> something like: "How many bits of information can be passed over the
>> link, allowing the display to present it in a way which can be
>> perceived by the user?" With dithering or DSC, that would be a higher
>> value than the physical link bpc.
> 
> Sure, but this is not that. This is only a part of that. You would
> also want to know what the monitor does with the signal, the depth of
> the data path to the panel, and so on. I'm sure those are completely
> off-topic for a KMS property.
> 
> The kernel driver won't know how acceptable temporal dithering, spatial
> dithering or lossy compression are, so I don't think it should be
> deciding how many bits of precision they add or subtract. Exactly this
> makes the link bpc property a well-defined fact rather than an estimate.
> 
> The documentation of 'link bpc' could be more explicit about this.
> 
>>
>> * There's no clear use case.
>>
>> This is generally a requirement for new KMS UAPI.
>>
>> The practical usefulness of the corresponding weston MR is dubious
>> per the concern above.
> 
> I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc rather
> than RGB 8 bpc is an excellent use case. I had another use case in
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686
> 
> Mario Kleiner had excellent cases as well.
> 
> Maybe these just need to be spelled more clearly in the commit message.
> 
>>> That the link-bpc property does not consider DSC and dithering?
>>> Two things which the max-bpc property also does not consider?  
>>
>> It's not (as much of) an issue with the "max bpc" property because
>> it's just an upper limit, the driver is free to use a lower effective
>> bpc.
> 
> FWIW, 'max bpc' is a workaround for faulty sink devices that claim to
> handle a depth but silently misbehave. This is also why I called for a
> "desired bpc" setting in the Weston MR, to not confuse with the "max
> bpc" setting.
> 
> 
> Thanks,
> pq