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

[Michel Dänzer]

On 3/26/26 14:53, Pekka Paalanen wrote:
> 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.

I don't disagree, this needs to be made clear in the documentation though, if not reflected in the property name itself.


>> * 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.

This series and the corresponding Weston MR aren't enough to address that use case though, are they? All they achieve is logging a potentially misleading warning.

It might make sense to combine this series and the Weston MR with whatever else is needed for that use case.


> I had another use case in
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686

That would need to take dithering into account as well?


> Mario Kleiner had excellent cases as well.

I raised unanswered questions on those.


>>> 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.

That's not the only use case (in fact I'm not sure I'd heard of this before). E.g. it can also be used in cases where some HW bottleneck prevents using maximum refresh rate at maximum bpc for all displays, to explicitly choose which display(s) to limit bpc for, allowing max bpc for the rest.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast