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

[Harry Wentland]

On 2026-03-31 08:50, Pekka Paalanen wrote:
> On Mon, 30 Mar 2026 14:52:23 -0400
> Harry Wentland <harry.wentland@xxxxxxx> 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.
> 

I don't like this as a blanket statement. There is a lot of policy that
intersects with HW nuances, whether it comes to power or otherwise.
Taking away driver vendor's abilities to optimize will hurt the Linux
ecosystem in the long run.

IMO this needs to be evaluated on a case by case basis. There are
many places where it does make sense to give userspace a greater
say on policy, but we don't want to push driver (HW specific) logic
up into userspace.

Harry

> 
> Thanks,
> pq