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

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

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

On Mon, 30 Mar 2026 14:52:23 -0400
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2026-03-30 12:57, Michel Dänzer wrote:
> > On 3/26/26 13:17, Nicolas Frattaroli wrote:  
> >> On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote:  
> >>> On 3/24/26 16:25, Nicolas Frattaroli wrote:  
> >>>> On Monday, 23 March 2026 18:27:41 Central European Standard Time Michel Dänzer wrote:  
> >>>>> On 3/23/26 17:55, Nicolas Frattaroli wrote:  
> >>>>>>
> >>>>>> "Someone might not understand its purpose" is, in my eyes, not a valid reason to
> >>>>>> not have this property, [...]  
> >>>>> Per my previous posts, that's not my concern.  
> >>>>
> >>>> Then what is your concern?  
> >>>
> >>> 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.  
> >>
> >> Dithering and DSC are supposed to be transparent, no?  
> > 
> > Not really, no. They achieve higher "effective" (as perceived by
> > the user) bpc using a lower physical bpc.
> > 
> >   
> >> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's
> >> still 10 bits.  
> > 
> > If DSC encodes user-perceived 10 bpc at a lower physical bpc, and
> > the "link bpc" property reports 10, that would satisfy my concern
> > for DSC. 
> 
> Conceptually I would understand DSC to not effect the reported bpc, so
> a 10bpc output bpc would be reported as 10bpc via the property, but
> DSC would compress that down to a lower value on the wire.
> 
> Dithering wouldn't do that. An 8bpc output would be reported as 8bpc
> even if dithering makes it perceptually look like 10bpc.

That seems quite arbitrary, but ok, that could work.

> I can understand the challenge of how to intelligently use it to
> report anything back to users. I could see some compositors being happy
> to use the bpc alone, while others might want to know dithering and/or
> DSC state (compression ratio?) as well.

People who care about the picture quality down to these levels will
likely want to know and learn about these techniques. They may also
want to explicitly control them.

In time, when these have been used enough in the wild, compositor
developers will learn what makes a difference and what does not, so
they will adjust their reporting to end users. The most important thing
for the kernel is it offer an unambiguous and stable UAPI for these.

Policy belongs in userspace.


Thanks,
pq

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