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

[Pekka Paalanen <pekka.paalanen@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 2956 bytes --]

Hi Michel,

I have some opinions as well.

On Tue, 24 Mar 2026 17:44:21 +0100
Michel Dänzer <michel.daenzer@mailbox.org> 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?

> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]