As somebody who writes software for neuroscience research, I would find this new property very useful.

Even if the 'link bpc' is not the perfectly accurate answer in presence of dithering or display stream compression, I think it could provide an idea about the minimum precision available, so a DRM client can at least make sure its minimum requirements are met. E.g., a 'link bpc' of 10 would at least guarantee 10 bpc, and effectively a bit more if spatial dithering is applied in addition. That said, I don't have practical experience with the effects of DSC, I don't have any suitable hardware. Afaik it is not truly lossless, but only (supposed to be, usually) perceptually lossless. It would be great to have some property that informs clients if DSC is active or not, or allow some control over that.

Also as somebody who has spent many hours of his life hunting down some sysfs or debugfs files for reporting such numbers, the files usually being differently named, at different paths, with different formats, or not existing at all, depending on kernel version and gpu configuration. I'd like to do less of that in the future.

In this field of application it is often very important to know about the actual precision of "what goes out of the computer", e.g., visual test stimuli. Scientists use different methods to verify their experimental stimulation setups, of different levels of rigorosity, including photometers, colorimeters etc. to measure the actual light emitted by a display. But knowing if things work, or where in the pipeline from app to photon they break or degrade, if they break, is useful, and the more the software can help with this, or warn about problems, the better for us.

Even if Wayland compositors wouldn't pick this up quickly, if it is a drm connector property, I think it would be accessible under a native X11 X-Server via RandR output properties -- and my kind of applications still heavily relies on native X11, as the Wayland eco system currently is not ready for the more demanding or non-trivial use cases in this field. Also, those properties are read-accessible to non-root, non-drm masters, so applications like mine could read the property even under leased drm connectors (Vulkan/WSI/display, OpenGL/EGL/drm), or probably even under a running Wayland desktop if Wayland protocol lacks the means to do so.

In the scenarios used by my app, the app often knows what an optimal setting for 'max bpc' or reported value from such a 'link bpc' would be, so it can be used to reconfigure things (under X11 RandR, or as a drm master), adapt to the situation, or at least warn the user if they are about to ruin their experimental data collection, possibly guide them a bit in troubleshooting.

But I could imagine regular desktop use cases, where a Wayland compositor can somewhat know what good minimum values for 'link bpc' would be, and maybe adapt, or give the user a hint about potentially degraded quality, and what to do about it ("Check your cables", "Reduce video resolution or refresh rate", "Run with less displays",...).

Similar to Nicolas rgb 10 bpc vs. yuv 10 bpc example for video playback: While all these are critical for apps like mine, or other pro apps depending on color quality, I'd assume a Wayland compositor could use the same constraints, even if the worst case desktop scenario may only be an underwhelmed user, if their HDR videos don't look as spiffy as they hoped.

- A HDR-10 display mode on a true HDR sink implies one really wants a 'link bpc' of at least 10 bpc, especially given the large nonlinearity of EOTF's like Perceptual Quantizer, or things will look poor. In a scientific research setting that would not just be a bummer, but degradation would be an absolute show stopper. Something one wants to fix, be it by checking/swapping cables, or maybe by selecting a video mode with lower bandwidth requirements, etc.

- Same is true for wide color gamut WCG color spaces, where one wants more than 8 bits to resolve the larger color volume fine enough for good results.

- I'd also assume or hope that a wayland client asking for a fullscreen (=possibly direct scanout capable) RGB10 framebuffer or fp16 fb or even RGBA16 fb would imply to the compositor that that client really wants to get at 10 bpc or even 12+ bpc out of the display connector. So having a too low link bpc would be a reason to possibly notify the user.

Excuse the verbose reply, but at least from my corner of applications this would have a big thumbs up.

Thanks,
-mario

On Fri, Mar 20, 2026 at 7:09 PM Nicolas Frattaroli <nicolas.frattaroli@collabora.com> 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.

This adds the other side of the equation, where userspace isn't
necessarily keen on blindly accepting the combination of output
link parameters the kernel degraded to. This allows userspace to
detect that an explicitly chosen value it tried did not work, and
try again with a different color format/VRR/bpc/etc.

A particular real-world use case is for playback of video content.
When playing back YUV 4:2:0 10-bit video content in a full-screen
setting, having RGB 10-bit degrade to YUV 4:2:0 10-bit rather than
RGB 8-bit is more desirable. However, this is a tradeoff only
userspace knows to make; the kernel doesn't necessarily know that
the framebuffer it has been handed as RGB 10-bit is secretly just
a video player's playback of YUV 4:2:0 10-bit content. As for
the property that let's userspace actually set the output color
format, that's a separate series of mine.

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.

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

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

Kind regards,
Nicolas Frattaroli