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