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. 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. In summary, I'm skeptical that this will be useful in practice in the current form. I do see potential for spurious bug reports based on the "link bpc" property having the "wrong" value though. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
