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

From: Michel Dänzer

Date: Wed Apr 01 2026 - 04:03:10 EST


On 3/31/26 16:21, Pekka Paalanen wrote:
> On Tue, 31 Mar 2026 14:56:22 +0200
> Michel Dänzer <michel.daenzer@xxxxxxxxxxx> wrote:
>> On 3/31/26 14:38, Pekka Paalanen wrote:
>>> On Tue, 31 Mar 2026 10:01:59 +0200
>>> Michel Dänzer <michel.daenzer@xxxxxxxxxxx> wrote:
>>>> On 3/26/26 14:53, Pekka Paalanen wrote:
>>>>> On Tue, 24 Mar 2026 17:44:21 +0100
>>>>> Michel Dänzer <michel.daenzer@xxxxxxxxxxx> 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.

What can be done when it's too low though? The only thing I can see is setting a higher "max bpc" value. If that's acceptable and helps though, why was the lower value set in the first place? (Otherwise the weston MR doesn't log the warning)


I feel like I'm still missing a piece of the picture for the practical use.


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