On 3/24/26 16:25, Nicolas Frattaroli wrote: > On Monday, 23 March 2026 18:27:41 Central European Standard Time Michel > Dänzer wrote: >> On 3/23/26 17:55, Nicolas Frattaroli wrote: >>> >>> "Someone might not understand its purpose" is, in my eyes, not a valid >>> reason to >>> not have this property, [...] >> Per my previous posts, that's not my concern. > > Then what is your concern?
Per my previous posts, my concerns are: * The meaning of the "link bpc" property value isn't defined well enough vs things like dithering or DSC, which will likely result in compositors / users overestimating what value they need / want, resulting in compositors spuriously rejecting configurations which would work perfectly fine, and/or spurious issue reports. With my compositor developer hat on, what I'd want to know is something like: "How many bits of information can be passed over the link, allowing the display to present it in a way which can be perceived by the user?" With dithering or DSC, that would be a higher value than the physical link bpc. * There's no clear use case. This is generally a requirement for new KMS UAPI. The practical usefulness of the corresponding weston MR is dubious per the concern above. > That the link-bpc property does not consider DSC and dithering? > Two things which the max-bpc property also does not consider? It's not (as much of) an issue with the "max bpc" property because it's just an upper limit, the driver is free to use a lower effective bpc. > If all you want is a clearer description of the property in the comment that > accompanies it, then I can do that, and I said I agree with this point. Patch 3 would need to take dithering & DSC into account as well. > But you seem to be arguing from a position of not wanting the property to > exist at all, [...] I'm not. However, per the first concern above, a not-well-defined property could be worse than none. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
