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

["Michel Dänzer" <michel.daenzer@mailbox.org>]

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.

Are you sure that's the case though?

I would be quite surprised if this was correspondingly the case for dithering.

Either way, the "link bpc" semantics regarding these should be explicitly documented.


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

Sounds like you misunderstood my concern.


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

I'm not assuming, I'm asking for this to be clarified.


> [...], you seem to be obsessed [...]

Not sure why you keep attacking me personally. I'm not trying to shoot down your proposal, I'm trying to prevent potential flaws I see with it. A bit more cooperative attitude would be nice.


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

The start of this thread is the cover letter of a 3-patch series.


> and I will not break the feedback loop semantics of this property to please you.

More ad hominem.


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

This isn't a good-faith argument either. Nobody asked for that.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast