On 3/21/26 03:33, Mario Kleiner wrote:
> 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.
There's a problem in the opposite direction: With dithering, the "link bpc"
property implies that the display link can transmit less information than it
actually can.
> 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.
FWIW, I mentioned DSC not because it's potentially lossy, but because it allows
transmitting a larger "real" (albeit potentially lossy) bpc over a smaller
physical bpc. If the "link bpc" property reported the latter, it would again
imply the link can transfer less information than it actually can.
> 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.
No doubt that generic KMS properties would be better than that, I'm just
skeptical that this specific property (alone) as currently defined is really
useful.
> 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,
How can it know that vs dithering?
> 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",...).
I see potential for false positives resulting in spurious issue reports.
> - 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.
Even with dithering? (Same question about the other scenarios you mentioned)
--
Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
