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

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

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

On Tue, 31 Mar 2026 14:56:22 +0200
Michel Dänzer <michel.daenzer@mailbox.org> wrote:

> On 3/31/26 14:38, Pekka Paalanen wrote:
> > 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:
> >>>     
> >>>> * 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?  
> 
> For the stated use case, e.g. a mechanism to control RGB vs YCbCr?

There is no need for that. Currently the driver chooses the color model
and depth on its own. We just want to make sure it's not too low.

This will remain useful when userspace can explicitly control more
things. I think all stream parameters should have an "auto" value and a
feedback property, plus a property to explicitly set something. That
allows userspace to light up anything any way possible, but also to try
and make decisions about what it exactly wants.

A consistent naming scheme for stream for setter vs. feedback
properties would be nice, though I'm not sure if that boat already
sailed.

> > Informing the user that the display quality may not be as expected
> > is the point.  
> 
> The warning implies that the "link bpc" value is expected to match
> the "max bpc" value, which generally isn't the case.

Yes, that's why I wrote
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686

> >>> 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.  
> 
> I agree that would be ideal, alas it's not current reality.

One step at a time, eyes on the prize.


Thanks,
pq


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