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

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

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

On Tue, 31 Mar 2026 10:01:59 +0200
Michel Dänzer <michel.daenzer@mailbox.org> wrote:

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

What do you believe is missing?

Informing the user that the display quality may not be as expected is
the point. Weston does not have any other kind of UI atm. than printing
to the log.

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

Yes, dithering could be an adverse effect or not sufficient. Hence the
'link bpc' property should not consider any kind of dithering, to be on
the safe side. I fully expect dithering to become explicitly
controllable, as policy belongs in userspace.

The point of dithering is to adjust the stimuli on screen, that is, to
make a visible difference on dithered vs. not. Maintaining a display
profile valid requires keeping the stimuli response as it was during
profiling. Therefore turning dithering on or off would invalidate the
profile in cases where dithering is useful.

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

That was what I came to understand when some years I dug into the
history to figure out why 'max bpc' was added initially. What you say
is another good use case considering the state of the UAPI which offers
no direct control.


Thanks,
pq

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