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

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

On Monday, 23 March 2026 11:55:34 Central European Standard Time Michel Dänzer wrote:
> On 3/20/26 19:02, Nicolas Frattaroli wrote:
> > On Friday, 20 March 2026 15:32:37 Central European Standard Time Michel Dänzer wrote:
> >> On 3/19/26 13:28, Nicolas Frattaroli wrote:
> >>> 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.
> >>>
> >>> There's a weston implementation at [1] which makes use of this new
> >>> property to warn when a user's requested bpc could not be reached.
> >>>
> >>> [1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850
> >>
> >> I see no description of a real-world use case, either in this series
> >> or in the weston MR, beyond logging a message when the "link bpc" &
> >> "max bpc" property values don't match. They are not expected to match
> >> in general, so I have a hard time seeing the usefulness of that.
> > 
> > Hello,
> > 
> > these are valid concerns. The problem being addressed is related to
> > userspace being able to detect whether the link has degraded due to,
> > say, a sketchy cable.
> > 
> > This patch started out as a method of forcing the output link's BPC
> > value to a certain value, but this is not desirable. The max bpc
> > property is already used to restrict the link's bpc due to sketchy
> > hardware that advertises a higher max bpc than it can actually
> > achieve.
> 
> Not really.
> 
> The "max bpc" property is simply an upper limit for the effective bpc that can be used by the driver; nothing more or less. The driver is free to use any lower bpc value though, that doesn't mean anything's wrong.
> 
> It doesn't imply that the "max bpc" value can actually be achieved under any circumstances.
> 
> The practical purpose is mainly to restrict bpc in cases where higher bpc would prevent e.g. higher refresh rate.

The max bpc property's upper limit is an arbitrary driver-set value as
you stated, but that's not what I'm talking about here. Please look at
the code in drm_atomic_uapi.c.

> 
> 
> > I agree that the weston implementation isn't a great showcase,
> > but it's actually supposed to compare link bpc with an explicitly
> > set max bpc config value, not the property value. The config value
> > exists to request a certain bpc.
> 
> Per above, the "max bpc" property isn't really useful for that.

This is straight up false. Setting a max bpc value in weston's config
sets the max bpc DRM property to that value, which in turn sets
max_requested_bpc. On atomic_check, the minimum of state->max_bpc
and state->max_requested_bpc is taken for the new value of
state->max_bpc, i.e. what is set through the property does constrain
the max bpc.

> 
> 
> >> Moreover, there's no description of what exactly the "link bpc" property
> >> value means, e.g. vs things like DSC or dithering, or how a compositor / 
> >> user would determine which value they need / want under given circumstances.
> > 
> > I agree that I should've expanded on this after splitting it out of the
> > HDMI patch. It's the output BPC as HDMI understands it. That means DSC is not
> > a factor. I don't know if any display protocols do dithering at the
> > protocol level, I only know some monitors dither internally, which isn't
> > something that can be detected.
> 
> I know AMD GPUs can do at least temporal dithering of the data they send over the link, I suspect non-temporal as well.
> 
> Either way, the user may be able to distinguish more information than the "link bpc" property value implies.
> 
> 
>