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

[Nicolas Frattaroli]

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? Or else why is
amdgpu forcing DSC on for everyone? This doesn't make sense. If a
link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits.
No compositor would care about the compressed-to actual bit depth on
the wire being 9 bits on the intake of a DSC decoder, it's not relevant
for their use case, they're not decoding DSC.

Making it consider DSC as part of the link bpc would lead to what you
describe, since now compositors would need to know the compression
algorithms of every single display protocol to correctly determine
whether unintended degradation has happened. Ignoring DSC, which is
what I am doing, would not do that.
 
> 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.

You're assuming link-bpc isn't precisely that. It is precisely that. It's
not the wire format. Nobody cares about how many bits are on the wire, they
care about the bit depth on the protocol level, that is, whether 10->8 bit
degradation has happened, not whether 10 bits have DSC applied to be actually
9 bits on the wire but it's not the same as uncompressed 9 bits would be
because compression doesn't work like that.

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

As per my previous responses, I outlined you the use case. However, you
seem to be obsessed with the weston MR that adds a warning. This is not
the use case. I will copy-paste my explanation of the use case again, for
your benefit:

A particular real-world use case is for playback of video content.
When playing back YUV 4:2:0 10-bit video content in a full-screen
setting, having RGB 10-bit degrade to YUV 4:2:0 10-bit rather than
RGB 8-bit is more desirable. However, this is a tradeoff only
userspace knows to make; the kernel doesn't necessarily know that
the framebuffer it has been handed as RGB 10-bit is secretly just
a video player's playback of YUV 4:2:0 10-bit content. As for
the property that let's userspace actually set the output color
format, that's a separate series of mine.

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

Yes it is. If I request 10 bpc but I'm somehow convinced that this means
"whatever bpc compresses to 10bpc with DSC" then it's not working as this
flawed interpretation would convince me. However, thankfully, nobody thinks
this.

> > If all you want is a clearer description of the property in the comment that
> > accompanies it, then I can do that, and I said I agree with this point.
> 
> Patch 3 would need to take dithering & DSC into account as well.

There is no patch 3, and I will not break the feedback loop semantics of this
property to please you. It ruins the actual intended use case, so I won't do it.

> > But you seem to be arguing from a position of not wanting the property to
> > exist at all, [...]
> 
> I'm not. However, per the first concern above, a not-well-defined
> property could be worse than none.

So should I remove max-bpc as well? It's not well defined after all.