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

[Michel Dänzer]

On 4/1/26 14:14, Nicolas Frattaroli wrote:
> On Wednesday, 1 April 2026 13:57:08 Central European Summer Time Xaver Hugl wrote:
>> Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli
>> <nicolas.frattaroli@xxxxxxxxxxxxx>:
>>>
>>> This series adds a new "link bpc" DRM property. It reflects the display
>>> link's actual achieved output bits per component, considering any
>>> degradation of the bit depth done by drivers for bandwidth or other
>>> reasons. The property's value is updated during an atomic commit, which
>>> is also when it fires an uevent if it changed to let userspace know.
>>
>> Hi,
>> I think it's a really good idea to have a property for knowing the
>> actual bpc of the link... however, I do have one big concern with this
>> API specifically: It only gives me this information after a modeset.
>>
>> With this limitation, I can at most show the user which bpc was chosen
>> after the apply display settings and have the end user manually test
>> and figure things out, but I cannot show in the UI which bpc will be
>> chosen with some configuration before they apply it, and I cannot do
>> atomic tests to find a desired tradeoff automatically on the
>> compositor side.
> 
> To do this I'd need to see if there's some feedback mechanism for
> the output configuration chosen by the atomic check phase, so that
> userspace can then run a DRM_MODE_ATOMIC_TEST_ONLY and get the value
> back somehow.
> 
> The current implementation wouldn't be able to do this since it
> updates the property on commit_tail. I'll need to look into whether
> drivers already have everything figured out with regards to link bpc
> in the check phase, and how that would best be communicated to
> userspace.

Taking both the Weston use case described in this thread and Xaver's requirements into account, a "min bpc" property complementing the "max bpc" one (as suggested by Ville before) might be better than "link bpc".

That might be a better fit even just for the Weston use case described in this thread, since AFAICT that only really cares about the minimum bpc, not the maximum.

The compositor could set "min bpc" to any value <= the "max bpc" one. If the driver can't make things work with effective bpc >= "min bpc", the commit fails. Setting both properties to the same value would allow selecting a specific bpc. That would allow compositors to find possible bpc permutations using TEST_ONLY commits, as described by Xaver.

Setting "min bpc" to 0 (which should probably be the default value) would allow any bpc, i.e. "auto" behaviour.


One potential issue with the "min bpc" property is that if one DRM master leaves it at a non-0 value, and a later DRM master doesn't know about it yet, it might cause surprising commit failures for the latter. This kind of issue already exists with other properties though. (Some kind of "default state" mechanism might help for solving this kind of issue)


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