drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++- drivers/gpu/drm/display/drm_hdmi_state_helper.c | 2 + drivers/gpu/drm/drm_atomic_helper.c | 9 +++ drivers/gpu/drm/drm_atomic_uapi.c | 2 + drivers/gpu/drm/drm_connector.c | 86 +++++++++++++++++++++++ include/drm/drm_connector.h | 16 +++++ 6 files changed, 129 insertions(+), 1 deletion(-)
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
---
Changes in v5:
- Split "drm/connector: hdmi: Add a 'link bpc' property" into two
patches; one adding the property, the other making use for it in the
HDMI helpers (Maxime)
- Apply Maxime's Ack to the two split patches as per the review
- Link to v4: https://lore.kernel.org/r/20260311-link-bpc-v4-0-51775e964720@collabora.com
Changes in v4:
- Throw out the workqueue and delayed work item
- Remove the drm_connector_update_link_bpc_state function
- Reimplement it by updating the property and firing the uevent in
commit_tail
- Check that the provided max_bpc value in attach_link_bpc_property is
within the expected range
- Clamp the connector state's link_bpc value between 8 and max_bpc so
that no value outside the declared range is ever written to the drm
property
- Update and reword doc strings
- Add an amdgpu implementation
- Link to v3: https://lore.kernel.org/r/20251022162843.1759-1-marius.vlad@collabora.com/T/
Changes in v3:
- remove VRR mention from commit description (Ville)
- add DRM_MODE_PROP_IMMUTABLE to flags (Ville)
- provide helpers functions for drivers to use (can be used by other
types of connectors, not just HDMI)
- send uevent informating userspace when 'link bpc' connector state
changed (Daniel @ https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850)
- added missing doc entry
- Link to v2: https://lore.kernel.org/r/20251006083043.3115-1-marius.vlad@collabora.com/T/
Changes in v2:
- replace return with EBUSY if connector already exists (Dmitry)
- add i-g-t test and an implementation for Weston (Dmitry)
- re-wording patch description (Jani)
- Link to v1: https://lore.kernel.org/r/20250801101750.1726-1-marius.vlad@collabora.com/T/
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Nicolas Frattaroli (3):
drm/connector: Add a 'link bpc' property
drm/connector: hdmi: Add support for 'link bpc' property
drm/amd/display: Add support for 'link bpc' property
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++-
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 2 +
drivers/gpu/drm/drm_atomic_helper.c | 9 +++
drivers/gpu/drm/drm_atomic_uapi.c | 2 +
drivers/gpu/drm/drm_connector.c | 86 +++++++++++++++++++++++
include/drm/drm_connector.h | 16 +++++
6 files changed, 129 insertions(+), 1 deletion(-)
---
base-commit: f4482de2c06e19b0c337b774e485755378990614
change-id: 20260309-link-bpc-d0afc475ac49
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli <nicolas.frattaroli@collabora.com>: > > 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. Hi, I think it's a really good idea to have a property for knowing the actual bpc of the link... however, I do have one big concern with this API specifically: It only gives me this information after a modeset. With this limitation, I can at most show the user which bpc was chosen after the apply display settings and have the end user manually test and figure things out, but I cannot show in the UI which bpc will be chosen with some configuration before they apply it, and I cannot do atomic tests to find a desired tradeoff automatically on the compositor side. As a side note, for future patches relevant for compositors, please cc wayland-devel. It really shouldn't be up to chance whether or not compositor developers that would later use the API find out about it before it's merged, and keeping track of all of dri-devel is way too much to ask from userspace developers. - Xaver
On Wed, Apr 01, 2026 at 01:57:08PM +0200, Xaver Hugl wrote: > Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli > <nicolas.frattaroli@collabora.com>: > > > > 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. > > Hi, > I think it's a really good idea to have a property for knowing the > actual bpc of the link... however, I do have one big concern with this > API specifically: It only gives me this information after a modeset. > > With this limitation, I can at most show the user which bpc was chosen > after the apply display settings and have the end user manually test > and figure things out, but I cannot show in the UI which bpc will be > chosen with some configuration before they apply it, and I cannot do > atomic tests to find a desired tradeoff automatically on the > compositor side. I think the idea of some kind of feedback properties in the atomic commit has come up before, but no one has ever tried to implement them. > > As a side note, for future patches relevant for compositors, please cc > wayland-devel. It really shouldn't be up to chance whether or not > compositor developers that would later use the API find out about it > before it's merged, and keeping track of all of dri-devel is way too > much to ask from userspace developers. > > - Xaver -- Ville Syrjälä Intel
On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > I think the idea of some kind of feedback properties in the atomic > commit has come up before, but no one has ever tried to implement them. Yeah, if you're looking for context on these, the last place I remember it coming up was wanting to know which other objects would potentially be dragged into a commit. For example, on ye olde (?) Intel platforms, if programming a different mode is actually stop-the-world where all other CRTCs get affected by a CDCLK change, being able to know that those other CRTCs would be affected before it happens, rather than random -EBUSY after the fact. Cheers, Daniel
On Wed, Apr 01, 2026 at 01:25:31PM +0100, Daniel Stone wrote: > On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > I think the idea of some kind of feedback properties in the atomic > > commit has come up before, but no one has ever tried to implement them. > > Yeah, if you're looking for context on these, the last place I > remember it coming up was wanting to know which other objects would > potentially be dragged into a commit. For example, on ye olde (?) > Intel platforms, if programming a different mode is actually > stop-the-world where all other CRTCs get affected by a CDCLK change, > being able to know that those other CRTCs would be affected before it > happens, rather than random -EBUSY after the fact. For the success cases I think it should be pretty straightforward to just walk the props in the commit again after the atomic check and write back all the feedback values from the computed state. I think adding this for error cases would be much harder. We'd have to somehow make sure the value(s) we write back to userspace are at least somewhat valid even though the state check may have failed half way through. Although that specific -EBUSY you mention I think is checked after the actual atomic check, so it would work there. Assuming we'd have a place for eg. the affected crtcs bitmask in the ioctl structure... And speaking of which, if you'll permit me to go off on another tangent, I have occasionally pondered introducing per-device properties. We could introduce a new object type for the whole device, and add a new enumeration thing to find it. Then per-device properties could be added to atomic commits exactly like any other properties. My original idea was to use this for some kind of device wide "power vs. performance" knob, but it could also be used for this affected crtcs bitmask feedback. -- Ville Syrjälä Intel
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
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
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. > 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. >> 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. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
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. > > >
On 3/23/26 13:05, Nicolas Frattaroli wrote: > 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. I'm not talking about the maximum value of the property itself either. The value of the "max bpc" property, which can be modified by user space, defines the upper limit for the effective bpc used by the driver. >>> 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. What I mean is that the "max bpc" property isn't useful for the purpose of "request a certain bpc". It only affects the upper limit, not the effective value, which can legitimately be lower. Logging a message in that case may be a false positive which may result in a spurious issue report. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On Monday, 23 March 2026 15:38:58 Central European Standard Time Michel Dänzer wrote: > On 3/23/26 13:05, Nicolas Frattaroli wrote: > > 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. > > I'm not talking about the maximum value of the property itself either. > > The value of the "max bpc" property, which can be modified by user space, defines the upper limit for the effective bpc used by the driver. Yes, I know what the max bpc property does. I do not think it defines a fixed bpc the driver was required to use, as if it did, the link bpc property would be useless. > >>> 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. > > What I mean is that the "max bpc" property isn't useful for the purpose of "request a certain bpc". Yes it is? It requests an upper limit for BPC and every driver will try to pick the highest that's practically possible. > It only affects the upper limit, not the effective value, which can legitimately be lower. I am aware, that is why the link bpc property is added, to evaluate what the driver ended up picking. See "practically possible" above. > Logging a message in that case may be a false positive which may result in a spurious issue report. That is not what any of this is used for. In the MR, it acts on the weston option of the name max-bpc, which incidentally sets the max bpc property, but is an explicit request by a user made through a config file. The use here is just a basic userspace use of it, the point is not to create a new warning out of nothing for the fun of it. The whole point of this property is to close the feedback loop between requesting a new bpc with max-bpc and seeing what comes out the other end with link-bpc. This answers all questions you should have about the definition of what bits per component is (same as with max bpc), and why this property should exist. "Someone might not understand its purpose" is, in my eyes, not a valid reason to not have this property, as this argument applies to every property.
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. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
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? That the link-bpc property does not consider DSC and dithering? Two things which the max-bpc property also does not consider? Please clearly state where your problem with this property is (and not with how your understanding of the Weston MR uses it) so that I can make forward progress here. 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. But you seem to be arguing from a position of not wanting the property to exist at all, which is not something I can address. Userspace needs a way to close the feedback loop here, or it won't be able to make the right content-specific trade-offs. Kind regards, Nicolas Frattaroli
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
Hi Michel, I have some opinions as well. On Tue, 24 Mar 2026 17:44:21 +0100 Michel Dänzer <michel.daenzer@mailbox.org> wrote: > 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. That is ok. Compositors need to understand what the numbers mean, how reliable they are, and act accordingly. Knowing the lower bound for link precision is already useful as it guarantees a minimum precision. It is up to the compositors to decide how they communicate this. Or course, assuming lossy compression is not too lossy. Maybe lossy compression should be forbidden by default unless explicitly enabled by userspace? > 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. Sure, but this is not that. This is only a part of that. You would also want to know what the monitor does with the signal, the depth of the data path to the panel, and so on. I'm sure those are completely off-topic for a KMS property. The kernel driver won't know how acceptable temporal dithering, spatial dithering or lossy compression are, so I don't think it should be deciding how many bits of precision they add or subtract. Exactly this makes the link bpc property a well-defined fact rather than an estimate. The documentation of 'link bpc' could be more explicit about this. > > * 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. I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc rather than RGB 8 bpc is an excellent use case. I had another use case in https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 Mario Kleiner had excellent cases as well. Maybe these just need to be spelled more clearly in the commit message. > > 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. FWIW, 'max bpc' is a workaround for faulty sink devices that claim to handle a depth but silently misbehave. This is also why I called for a "desired bpc" setting in the Weston MR, to not confuse with the "max bpc" setting. Thanks, pq
On 3/26/26 14:53, Pekka Paalanen wrote: > On Tue, 24 Mar 2026 17:44:21 +0100 > Michel Dänzer <michel.daenzer@mailbox.org> wrote: > >> 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. > > That is ok. Compositors need to understand what the numbers mean, how > reliable they are, and act accordingly. Knowing the lower bound for > link precision is already useful as it guarantees a minimum precision. I don't disagree, this needs to be made clear in the documentation though, if not reflected in the property name itself. >> * 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. > > I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc rather > than RGB 8 bpc is an excellent use case. This series and the corresponding Weston MR aren't enough to address that use case though, are they? All they achieve is logging a potentially misleading warning. It might make sense to combine this series and the Weston MR with whatever else is needed for that use case. > I had another use case in > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 That would need to take dithering into account as well? > Mario Kleiner had excellent cases as well. I raised unanswered questions on those. >>> 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. > > FWIW, 'max bpc' is a workaround for faulty sink devices that claim to > handle a depth but silently misbehave. That's not the only use case (in fact I'm not sure I'd heard of this before). E.g. it can also be used in cases where some HW bottleneck prevents using maximum refresh rate at maximum bpc for all displays, to explicitly choose which display(s) to limit bpc for, allowing max bpc for the rest. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On Tue, 31 Mar 2026 10:01:59 +0200 Michel Dänzer <michel.daenzer@mailbox.org> wrote: > On 3/26/26 14:53, Pekka Paalanen wrote: > > On Tue, 24 Mar 2026 17:44:21 +0100 > > Michel Dänzer <michel.daenzer@mailbox.org> wrote: > > > >> 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. > > > > That is ok. Compositors need to understand what the numbers mean, how > > reliable they are, and act accordingly. Knowing the lower bound for > > link precision is already useful as it guarantees a minimum precision. > > I don't disagree, this needs to be made clear in the documentation > though, if not reflected in the property name itself. > > > >> * 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. > > > > I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc > > rather than RGB 8 bpc is an excellent use case. > > This series and the corresponding Weston MR aren't enough to address > that use case though, are they? All they achieve is logging a > potentially misleading warning. > > It might make sense to combine this series and the Weston MR with > whatever else is needed for that use case. What do you believe is missing? Informing the user that the display quality may not be as expected is the point. Weston does not have any other kind of UI atm. than printing to the log. > > I had another use case in > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 > > That would need to take dithering into account as well? Yes, dithering could be an adverse effect or not sufficient. Hence the 'link bpc' property should not consider any kind of dithering, to be on the safe side. I fully expect dithering to become explicitly controllable, as policy belongs in userspace. The point of dithering is to adjust the stimuli on screen, that is, to make a visible difference on dithered vs. not. Maintaining a display profile valid requires keeping the stimuli response as it was during profiling. Therefore turning dithering on or off would invalidate the profile in cases where dithering is useful. > > Mario Kleiner had excellent cases as well. > > I raised unanswered questions on those. > > > >>> 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. > > > > FWIW, 'max bpc' is a workaround for faulty sink devices that claim to > > handle a depth but silently misbehave. > > That's not the only use case (in fact I'm not sure I'd heard of this > before). E.g. it can also be used in cases where some HW bottleneck > prevents using maximum refresh rate at maximum bpc for all displays, > to explicitly choose which display(s) to limit bpc for, allowing max > bpc for the rest. That was what I came to understand when some years I dug into the history to figure out why 'max bpc' was added initially. What you say is another good use case considering the state of the UAPI which offers no direct control. Thanks, pq
On 3/31/26 14:38, Pekka Paalanen wrote: > On Tue, 31 Mar 2026 10:01:59 +0200 > Michel Dänzer <michel.daenzer@mailbox.org> wrote: >> On 3/26/26 14:53, Pekka Paalanen wrote: >>> On Tue, 24 Mar 2026 17:44:21 +0100 >>> Michel Dänzer <michel.daenzer@mailbox.org> wrote: >>> >>>> * 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. >>> >>> I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc >>> rather than RGB 8 bpc is an excellent use case. >> >> This series and the corresponding Weston MR aren't enough to address >> that use case though, are they? All they achieve is logging a >> potentially misleading warning. >> >> It might make sense to combine this series and the Weston MR with >> whatever else is needed for that use case. > > What do you believe is missing? For the stated use case, e.g. a mechanism to control RGB vs YCbCr? > Informing the user that the display quality may not be as expected is > the point. The warning implies that the "link bpc" value is expected to match the "max bpc" value, which generally isn't the case. >>> I had another use case in >>> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 >> >> That would need to take dithering into account as well? > > Yes, dithering could be an adverse effect or not sufficient. Hence the > 'link bpc' property should not consider any kind of dithering, to be on > the safe side. I fully expect dithering to become explicitly > controllable, as policy belongs in userspace. I agree that would be ideal, alas it's not current reality. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On Tue, 31 Mar 2026 14:56:22 +0200 Michel Dänzer <michel.daenzer@mailbox.org> wrote: > On 3/31/26 14:38, Pekka Paalanen wrote: > > On Tue, 31 Mar 2026 10:01:59 +0200 > > Michel Dänzer <michel.daenzer@mailbox.org> wrote: > >> On 3/26/26 14:53, Pekka Paalanen wrote: > >>> On Tue, 24 Mar 2026 17:44:21 +0100 > >>> Michel Dänzer <michel.daenzer@mailbox.org> wrote: > >>> > >>>> * 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. > >>> > >>> I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc > >>> rather than RGB 8 bpc is an excellent use case. > >> > >> This series and the corresponding Weston MR aren't enough to address > >> that use case though, are they? All they achieve is logging a > >> potentially misleading warning. > >> > >> It might make sense to combine this series and the Weston MR with > >> whatever else is needed for that use case. > > > > What do you believe is missing? > > For the stated use case, e.g. a mechanism to control RGB vs YCbCr? There is no need for that. Currently the driver chooses the color model and depth on its own. We just want to make sure it's not too low. This will remain useful when userspace can explicitly control more things. I think all stream parameters should have an "auto" value and a feedback property, plus a property to explicitly set something. That allows userspace to light up anything any way possible, but also to try and make decisions about what it exactly wants. A consistent naming scheme for stream for setter vs. feedback properties would be nice, though I'm not sure if that boat already sailed. > > Informing the user that the display quality may not be as expected > > is the point. > > The warning implies that the "link bpc" value is expected to match > the "max bpc" value, which generally isn't the case. Yes, that's why I wrote https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 > >>> I had another use case in > >>> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 > >> > >> That would need to take dithering into account as well? > > > > Yes, dithering could be an adverse effect or not sufficient. Hence the > > 'link bpc' property should not consider any kind of dithering, to be on > > the safe side. I fully expect dithering to become explicitly > > controllable, as policy belongs in userspace. > > I agree that would be ideal, alas it's not current reality. One step at a time, eyes on the prize. Thanks, pq
On 3/31/26 16:21, Pekka Paalanen wrote: > On Tue, 31 Mar 2026 14:56:22 +0200 > Michel Dänzer <michel.daenzer@mailbox.org> wrote: >> On 3/31/26 14:38, Pekka Paalanen wrote: >>> On Tue, 31 Mar 2026 10:01:59 +0200 >>> Michel Dänzer <michel.daenzer@mailbox.org> wrote: >>>> On 3/26/26 14:53, Pekka Paalanen wrote: >>>>> On Tue, 24 Mar 2026 17:44:21 +0100 >>>>> Michel Dänzer <michel.daenzer@mailbox.org> wrote: >>>>> >>>>>> * 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. >>>>> >>>>> I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc >>>>> rather than RGB 8 bpc is an excellent use case. >>>> >>>> This series and the corresponding Weston MR aren't enough to address >>>> that use case though, are they? All they achieve is logging a >>>> potentially misleading warning. >>>> >>>> It might make sense to combine this series and the Weston MR with >>>> whatever else is needed for that use case. >>> >>> What do you believe is missing? >> >> For the stated use case, e.g. a mechanism to control RGB vs YCbCr? > > There is no need for that. Currently the driver chooses the color model > and depth on its own. We just want to make sure it's not too low. What can be done when it's too low though? The only thing I can see is setting a higher "max bpc" value. If that's acceptable and helps though, why was the lower value set in the first place? (Otherwise the weston MR doesn't log the warning) I feel like I'm still missing a piece of the picture for the practical use. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On 2026-03-26 09:53, Pekka Paalanen wrote: > Hi Michel, > > I have some opinions as well. > > On Tue, 24 Mar 2026 17:44:21 +0100 > Michel Dänzer <michel.daenzer@mailbox.org> wrote: > >> 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. > > That is ok. Compositors need to understand what the numbers mean, how > reliable they are, and act accordingly. Knowing the lower bound for > link precision is already useful as it guarantees a minimum precision. > It is up to the compositors to decide how they communicate this. > > Or course, assuming lossy compression is not too lossy. Maybe > lossy compression should be forbidden by default unless explicitly > enabled by userspace? > I disagree. While technically lossy, DSC is perceptually lossless, at least according to the designers of DSC. If I'm not mistaken this is all based on extensive studies. The decision to enable DSC or not has an impact on the power consumption of the HW, in ways that are often nuanced. Userspace has no way to know or understand these nuances. This should be in control of the driver. At most I could see a "never do DSC or dither" toggle, if one is really concerned about this, but I don't realistically see use-cases where this would improve user experience, even for users that care about color work and correctness. The YCbCr420 case is different. We probably want a way for userspace to understand that half 3/4 of chroma values are being tossed out. This would be significant for RGB content but insignificant for YCbCr420 content. Harry >> 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. > > Sure, but this is not that. This is only a part of that. You would > also want to know what the monitor does with the signal, the depth of > the data path to the panel, and so on. I'm sure those are completely > off-topic for a KMS property. > > The kernel driver won't know how acceptable temporal dithering, spatial > dithering or lossy compression are, so I don't think it should be > deciding how many bits of precision they add or subtract. Exactly this > makes the link bpc property a well-defined fact rather than an estimate. > > The documentation of 'link bpc' could be more explicit about this. > >> >> * 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. > > I think the example of RGB 10 bpc to be degraded to YCbCr 10 bpc rather > than RGB 8 bpc is an excellent use case. I had another use case in > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1850#note_3115686 > > Mario Kleiner had excellent cases as well. > > Maybe these just need to be spelled more clearly in the commit message. > >>> 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. > > FWIW, 'max bpc' is a workaround for faulty sink devices that claim to > handle a depth but silently misbehave. This is also why I called for a > "desired bpc" setting in the Weston MR, to not confuse with the "max > bpc" setting. > > > Thanks, > pq
On Mon, 30 Mar 2026 15:01:33 -0400 Harry Wentland <harry.wentland@amd.com> wrote: > On 2026-03-26 09:53, Pekka Paalanen wrote: > > Hi Michel, > > > > I have some opinions as well. > > > > On Tue, 24 Mar 2026 17:44:21 +0100 > > Michel Dänzer <michel.daenzer@mailbox.org> wrote: > > > >> 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. > > > > That is ok. Compositors need to understand what the numbers mean, how > > reliable they are, and act accordingly. Knowing the lower bound for > > link precision is already useful as it guarantees a minimum precision. > > It is up to the compositors to decide how they communicate this. > > > > Or course, assuming lossy compression is not too lossy. Maybe > > lossy compression should be forbidden by default unless explicitly > > enabled by userspace? > > > > I disagree. While technically lossy, DSC is perceptually lossless, at > least according to the designers of DSC. If I'm not mistaken this is > all based on extensive studies. > > The decision to enable DSC or not has an impact on the power consumption > of the HW, in ways that are often nuanced. Userspace has no way to know > or understand these nuances. This should be in control of the driver. I guess time will tell. Are you saying that enabling DSC might have disadvantages aside from image quality? > At most I could see a "never do DSC or dither" toggle, if one is really > concerned about this, but I don't realistically see use-cases where this > would improve user experience, even for users that care about color work > and correctness. I'm not familiar with DSC, so I cannot criticise it. Dithering OTOH seems to be obviously suspect though. Temporal dithering - what if your refresh rate is 30 Hz for some movie playback? Spatial dithering - what if you have a low-resolution screen? I would not assume that dithering is always ok, and always achieves its theoretical results. > The YCbCr420 case is different. We probably want a way for userspace to > understand that half 3/4 of chroma values are being tossed out. This > would be significant for RGB content but insignificant for YCbCr420 > content. Do you mean full resolution vs. chroma sub-sampled to 2x2 blocks? I would again not assume "insignificant", because it depends on the picture content and angular pixel density (can you see individual pixels at your viewing distance). Gray-scale text will be fine, but colored text is another question. I'm fine with proceeding with these assumptions, as long as it is acknowledged that these assumptions might turn out false later and have a contingency plan. Thanks, pq
On 2026-03-31 06:28, Pekka Paalanen wrote: > On Mon, 30 Mar 2026 15:01:33 -0400 > Harry Wentland <harry.wentland@amd.com> wrote: > >> On 2026-03-26 09:53, Pekka Paalanen wrote: >>> Hi Michel, >>> >>> I have some opinions as well. >>> >>> On Tue, 24 Mar 2026 17:44:21 +0100 >>> Michel Dänzer <michel.daenzer@mailbox.org> wrote: >>> >>>> 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. >>> >>> That is ok. Compositors need to understand what the numbers mean, how >>> reliable they are, and act accordingly. Knowing the lower bound for >>> link precision is already useful as it guarantees a minimum precision. >>> It is up to the compositors to decide how they communicate this. >>> >>> Or course, assuming lossy compression is not too lossy. Maybe >>> lossy compression should be forbidden by default unless explicitly >>> enabled by userspace? >>> >> >> I disagree. While technically lossy, DSC is perceptually lossless, at >> least according to the designers of DSC. If I'm not mistaken this is >> all based on extensive studies. >> >> The decision to enable DSC or not has an impact on the power consumption >> of the HW, in ways that are often nuanced. Userspace has no way to know >> or understand these nuances. This should be in control of the driver. > > I guess time will tell. > > Are you saying that enabling DSC might have disadvantages aside from > image quality? > The opposite; enabling DSC might have advantages, in particular in power efficiency. And image quality impacts are negligible or (perceptually) non-existant, from my understanding. Afaik, Apple, which prides itself on image quality and being a platform for content producers, enables DSC by default on their systems. >> At most I could see a "never do DSC or dither" toggle, if one is really >> concerned about this, but I don't realistically see use-cases where this >> would improve user experience, even for users that care about color work >> and correctness. > > I'm not familiar with DSC, so I cannot criticise it. Dithering OTOH > seems to be obviously suspect though. > > Temporal dithering - what if your refresh rate is 30 Hz for some movie > playback? > > Spatial dithering - what if you have a low-resolution screen? > > I would not assume that dithering is always ok, and always achieves its > theoretical results. > Quite possibly, but we haven't really seen complaints about dither other than in scenarios where people explictly test that input pixels equal output pixels exactly. >> The YCbCr420 case is different. We probably want a way for userspace to >> understand that half 3/4 of chroma values are being tossed out. This >> would be significant for RGB content but insignificant for YCbCr420 >> content. > > Do you mean full resolution vs. chroma sub-sampled to 2x2 blocks? I > would again not assume "insignificant", because it depends on the > picture content and angular pixel density (can you see individual > pixels at your viewing distance). Gray-scale text will be fine, but > colored text is another question. > Yes. I think downgrading an output to YCbCr420 (chroma sub-sampled to 2x2 blocks) is a significant image quality impact. > I'm fine with proceeding with these assumptions, as long as it is > acknowledged that these assumptions might turn out false later and have > a contingency plan. > I guess that goes to Michel's question about what's expected of compositors here and whether there is clarity... I'm not sure I really have an answer on that other than documenting our expectations. Harry > > Thanks, > pq
On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote: > 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. Dithering and DSC are supposed to be transparent, no? Or else why is amdgpu forcing DSC on for everyone? This doesn't make sense. If a link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits. No compositor would care about the compressed-to actual bit depth on the wire being 9 bits on the intake of a DSC decoder, it's not relevant for their use case, they're not decoding DSC. Making it consider DSC as part of the link bpc would lead to what you describe, since now compositors would need to know the compression algorithms of every single display protocol to correctly determine whether unintended degradation has happened. Ignoring DSC, which is what I am doing, would not do that. > 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. You're assuming link-bpc isn't precisely that. It is precisely that. It's not the wire format. Nobody cares about how many bits are on the wire, they care about the bit depth on the protocol level, that is, whether 10->8 bit degradation has happened, not whether 10 bits have DSC applied to be actually 9 bits on the wire but it's not the same as uncompressed 9 bits would be because compression doesn't work like that. > * 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. As per my previous responses, I outlined you the use case. However, you seem to be obsessed with the weston MR that adds a warning. This is not the use case. I will copy-paste my explanation of the use case again, for your benefit: 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. > > 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. Yes it is. If I request 10 bpc but I'm somehow convinced that this means "whatever bpc compresses to 10bpc with DSC" then it's not working as this flawed interpretation would convince me. However, thankfully, nobody thinks this. > > 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. There is no patch 3, and I will not break the feedback loop semantics of this property to please you. It ruins the actual intended use case, so I won't do it. > > 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. So should I remove max-bpc as well? It's not well defined after all.
On 3/26/26 13:17, Nicolas Frattaroli wrote: > On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote: >> 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. > > Dithering and DSC are supposed to be transparent, no? Not really, no. They achieve higher "effective" (as perceived by the user) bpc using a lower physical bpc. > If a link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits. If DSC encodes user-perceived 10 bpc at a lower physical bpc, and the "link bpc" property reports 10, that would satisfy my concern for DSC. Are you sure that's the case though? I would be quite surprised if this was correspondingly the case for dithering. Either way, the "link bpc" semantics regarding these should be explicitly documented. > No compositor would care about the compressed-to actual bit depth on > the wire being 9 bits on the intake of a DSC decoder, it's not relevant > for their use case, they're not decoding DSC. > > Making it consider DSC as part of the link bpc would lead to what you > describe, since now compositors would need to know the compression > algorithms of every single display protocol to correctly determine > whether unintended degradation has happened. Ignoring DSC, which is > what I am doing, would not do that. Sounds like you misunderstood my concern. >> 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. > > You're assuming link-bpc isn't precisely that. I'm not assuming, I'm asking for this to be clarified. > [...], you seem to be obsessed [...] Not sure why you keep attacking me personally. I'm not trying to shoot down your proposal, I'm trying to prevent potential flaws I see with it. A bit more cooperative attitude would be nice. >>> 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. > > There is no patch 3, The start of this thread is the cover letter of a 3-patch series. > and I will not break the feedback loop semantics of this property to please you. More ad hominem. >>> 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. > > So should I remove max-bpc as well? It's not well defined after all. This isn't a good-faith argument either. Nobody asked for that. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On 2026-03-30 12:57, Michel Dänzer wrote: > On 3/26/26 13:17, Nicolas Frattaroli wrote: >> On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote: >>> 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. >> >> Dithering and DSC are supposed to be transparent, no? > > Not really, no. They achieve higher "effective" (as perceived by the user) bpc using a lower physical bpc. > > >> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's still 10 bits. > > If DSC encodes user-perceived 10 bpc at a lower physical bpc, and the "link bpc" property reports 10, that would satisfy my concern for DSC. > Conceptually I would understand DSC to not effect the reported bpc, so a 10bpc output bpc would be reported as 10bpc via the property, but DSC would compress that down to a lower value on the wire. Dithering wouldn't do that. An 8bpc output would be reported as 8bpc even if dithering makes it perceptually look like 10bpc. I can understand the challenge of how to intelligently use it to report anything back to users. I could see some compositors being happy to use the bpc alone, while others might want to know dithering and/or DSC state (compression ratio?) as well. Harry > Are you sure that's the case though? > > I would be quite surprised if this was correspondingly the case for dithering. > > Either way, the "link bpc" semantics regarding these should be explicitly documented. > > >> No compositor would care about the compressed-to actual bit depth on >> the wire being 9 bits on the intake of a DSC decoder, it's not relevant >> for their use case, they're not decoding DSC. >> >> Making it consider DSC as part of the link bpc would lead to what you >> describe, since now compositors would need to know the compression >> algorithms of every single display protocol to correctly determine >> whether unintended degradation has happened. Ignoring DSC, which is >> what I am doing, would not do that. > > Sounds like you misunderstood my concern. > > >>> 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. >> >> You're assuming link-bpc isn't precisely that. > > I'm not assuming, I'm asking for this to be clarified. > > >> [...], you seem to be obsessed [...] > > Not sure why you keep attacking me personally. I'm not trying to shoot down your proposal, I'm trying to prevent potential flaws I see with it. A bit more cooperative attitude would be nice. > > >>>> 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. >> >> There is no patch 3, > > The start of this thread is the cover letter of a 3-patch series. > > >> and I will not break the feedback loop semantics of this property to please you. > > More ad hominem. > > >>>> 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. >> >> So should I remove max-bpc as well? It's not well defined after all. > > This isn't a good-faith argument either. Nobody asked for that. > >
On Mon, 30 Mar 2026 14:52:23 -0400 Harry Wentland <harry.wentland@amd.com> wrote: > On 2026-03-30 12:57, Michel Dänzer wrote: > > On 3/26/26 13:17, Nicolas Frattaroli wrote: > >> On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote: > >>> 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. > >> > >> Dithering and DSC are supposed to be transparent, no? > > > > Not really, no. They achieve higher "effective" (as perceived by > > the user) bpc using a lower physical bpc. > > > > > >> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's > >> still 10 bits. > > > > If DSC encodes user-perceived 10 bpc at a lower physical bpc, and > > the "link bpc" property reports 10, that would satisfy my concern > > for DSC. > > Conceptually I would understand DSC to not effect the reported bpc, so > a 10bpc output bpc would be reported as 10bpc via the property, but > DSC would compress that down to a lower value on the wire. > > Dithering wouldn't do that. An 8bpc output would be reported as 8bpc > even if dithering makes it perceptually look like 10bpc. That seems quite arbitrary, but ok, that could work. > I can understand the challenge of how to intelligently use it to > report anything back to users. I could see some compositors being happy > to use the bpc alone, while others might want to know dithering and/or > DSC state (compression ratio?) as well. People who care about the picture quality down to these levels will likely want to know and learn about these techniques. They may also want to explicitly control them. In time, when these have been used enough in the wild, compositor developers will learn what makes a difference and what does not, so they will adjust their reporting to end users. The most important thing for the kernel is it offer an unambiguous and stable UAPI for these. Policy belongs in userspace. Thanks, pq
On 2026-03-31 08:50, Pekka Paalanen wrote: > On Mon, 30 Mar 2026 14:52:23 -0400 > Harry Wentland <harry.wentland@amd.com> wrote: > >> On 2026-03-30 12:57, Michel Dänzer wrote: >>> On 3/26/26 13:17, Nicolas Frattaroli wrote: >>>> On Tuesday, 24 March 2026 17:44:21 Central European Standard Time you wrote: >>>>> 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. >>>> >>>> Dithering and DSC are supposed to be transparent, no? >>> >>> Not really, no. They achieve higher "effective" (as perceived by >>> the user) bpc using a lower physical bpc. >>> >>> >>>> If a link bpc is 10 but DSC is on so it's 9 on the wire, it's >>>> still 10 bits. >>> >>> If DSC encodes user-perceived 10 bpc at a lower physical bpc, and >>> the "link bpc" property reports 10, that would satisfy my concern >>> for DSC. >> >> Conceptually I would understand DSC to not effect the reported bpc, so >> a 10bpc output bpc would be reported as 10bpc via the property, but >> DSC would compress that down to a lower value on the wire. >> >> Dithering wouldn't do that. An 8bpc output would be reported as 8bpc >> even if dithering makes it perceptually look like 10bpc. > > That seems quite arbitrary, but ok, that could work. > >> I can understand the challenge of how to intelligently use it to >> report anything back to users. I could see some compositors being happy >> to use the bpc alone, while others might want to know dithering and/or >> DSC state (compression ratio?) as well. > > People who care about the picture quality down to these levels will > likely want to know and learn about these techniques. They may also > want to explicitly control them. > > In time, when these have been used enough in the wild, compositor > developers will learn what makes a difference and what does not, so > they will adjust their reporting to end users. The most important thing > for the kernel is it offer an unambiguous and stable UAPI for these. > > Policy belongs in userspace. > I don't like this as a blanket statement. There is a lot of policy that intersects with HW nuances, whether it comes to power or otherwise. Taking away driver vendor's abilities to optimize will hurt the Linux ecosystem in the long run. IMO this needs to be evaluated on a case by case basis. There are many places where it does make sense to give userspace a greater say on policy, but we don't want to push driver (HW specific) logic up into userspace. Harry > > Thanks, > pq
Hi Harry, On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote: > On 2026-03-31 08:50, Pekka Paalanen wrote: > > People who care about the picture quality down to these levels will > > likely want to know and learn about these techniques. They may also > > want to explicitly control them. > > > > In time, when these have been used enough in the wild, compositor > > developers will learn what makes a difference and what does not, so > > they will adjust their reporting to end users. The most important thing > > for the kernel is it offer an unambiguous and stable UAPI for these. > > > > Policy belongs in userspace. > > I don't like this as a blanket statement. There is a lot of policy that > intersects with HW nuances, whether it comes to power or otherwise. > Taking away driver vendor's abilities to optimize will hurt the Linux > ecosystem in the long run. > > IMO this needs to be evaluated on a case by case basis. There are > many places where it does make sense to give userspace a greater > say on policy, but we don't want to push driver (HW specific) logic > up into userspace. It's not something that's _just_ specific to a particular display-controller manufacturer or a particular IP generation though. It very much depends on the usecase. If you have a laptop and you're trying to give a presentation, applying dithering and/or DSC makes a lot of sense: you don't want your battery to die, and the projector's probably going to obliterate half the colour anyway, so might as well as go for the most efficient thing. If your laptop is plugged into your big display at home to write code, applying DSC to cram the highest possible resolution + refresh in would make sense. But if dithering only results in a marginal power saving, and your laptop is charging anyway - why bother degrading visual acuity? If you're a media player, then you're in a good position to know what would be good to go over the wire, because you know (& are possibly in control of) the format over what comes in in the first place. But everyone's tradeoffs are different, which is why sometimes the best choice is to ultimately leave it up to the user. If you dig into any media playback device (STBs running Android TV, Apple TV, Fire TV, et al), you'll see that all of them ultimately allow overrides for bpc / colour model / subsampling / etc. Those aren't just there for fun, but because they are usable to real people, and it's not possible for Amlogic or MediaTek or Rockchip or whoever to statically decide that a certain configuration is going to be best everywhere. Right now we have drivers making magic per-vendor/SKU decisions, without even so much as a feedback mechanism to userspace (unless you count debugfs, maybe) so it can even figure out what's going on, let alone control it. To properly support some of those usecases, userspace needs to be able to control what goes out on the wire, but as a first step, it just wants to be informed of what the driver even did with the properties we gave it. The end game of this isn't Weston logging something to stdout, it's to surface things to userspace so it can guide the kernel into making a good decision for usecases that may not be ones the silicon vendor decided was 'probably the best thing' however many years ago. Cheers, Daniel
On 2026-04-01 04:40, Daniel Stone wrote: > Hi Harry, > > On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote: >> On 2026-03-31 08:50, Pekka Paalanen wrote: >>> People who care about the picture quality down to these levels will >>> likely want to know and learn about these techniques. They may also >>> want to explicitly control them. >>> >>> In time, when these have been used enough in the wild, compositor >>> developers will learn what makes a difference and what does not, so >>> they will adjust their reporting to end users. The most important thing >>> for the kernel is it offer an unambiguous and stable UAPI for these. >>> >>> Policy belongs in userspace. >> >> I don't like this as a blanket statement. There is a lot of policy that >> intersects with HW nuances, whether it comes to power or otherwise. >> Taking away driver vendor's abilities to optimize will hurt the Linux >> ecosystem in the long run. >> >> IMO this needs to be evaluated on a case by case basis. There are >> many places where it does make sense to give userspace a greater >> say on policy, but we don't want to push driver (HW specific) logic >> up into userspace. > > It's not something that's _just_ specific to a particular > display-controller manufacturer or a particular IP generation though. > It very much depends on the usecase. > > If you have a laptop and you're trying to give a presentation, > applying dithering and/or DSC makes a lot of sense: you don't want > your battery to die, and the projector's probably going to obliterate > half the colour anyway, so might as well as go for the most efficient > thing. > > If your laptop is plugged into your big display at home to write code, > applying DSC to cram the highest possible resolution + refresh in > would make sense. But if dithering only results in a marginal power > saving, and your laptop is charging anyway - why bother degrading > visual acuity? > > If you're a media player, then you're in a good position to know what > would be good to go over the wire, because you know (& are possibly in > control of) the format over what comes in in the first place. > > But everyone's tradeoffs are different, which is why sometimes the > best choice is to ultimately leave it up to the user. If you dig into > any media playback device (STBs running Android TV, Apple TV, Fire TV, > et al), you'll see that all of them ultimately allow overrides for bpc > / colour model / subsampling / etc. Those aren't just there for fun, > but because they are usable to real people, and it's not possible for > Amlogic or MediaTek or Rockchip or whoever to statically decide that a > certain configuration is going to be best everywhere. > > Right now we have drivers making magic per-vendor/SKU decisions, > without even so much as a feedback mechanism to userspace (unless you > count debugfs, maybe) so it can even figure out what's going on, let > alone control it. To properly support some of those usecases, > userspace needs to be able to control what goes out on the wire, but > as a first step, it just wants to be informed of what the driver even > did with the properties we gave it. > > The end game of this isn't Weston logging something to stdout, it's to > surface things to userspace so it can guide the kernel into making a > good decision for usecases that may not be ones the silicon vendor > decided was 'probably the best thing' however many years ago. > I agree with you. But I wanted to respond to the statement that "policy belongs in userspace" and add a bit more nuance. It depends on the use-case and in any case, it's important drivers have the ability to set a good default policy for a given HW. We're still missing a lot of toggles to allow userspace to select a desired policy and I'm sure we'll be able to add those where needed but I agree with Michel and Ville that we need to get the end-to-end implementation right. Harry > Cheers, > Daniel
On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote: > Hi Harry, > > On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote: > > On 2026-03-31 08:50, Pekka Paalanen wrote: > > > People who care about the picture quality down to these levels will > > > likely want to know and learn about these techniques. They may also > > > want to explicitly control them. > > > > > > In time, when these have been used enough in the wild, compositor > > > developers will learn what makes a difference and what does not, so > > > they will adjust their reporting to end users. The most important thing > > > for the kernel is it offer an unambiguous and stable UAPI for these. > > > > > > Policy belongs in userspace. > > > > I don't like this as a blanket statement. There is a lot of policy that > > intersects with HW nuances, whether it comes to power or otherwise. > > Taking away driver vendor's abilities to optimize will hurt the Linux > > ecosystem in the long run. > > > > IMO this needs to be evaluated on a case by case basis. There are > > many places where it does make sense to give userspace a greater > > say on policy, but we don't want to push driver (HW specific) logic > > up into userspace. > > It's not something that's _just_ specific to a particular > display-controller manufacturer or a particular IP generation though. > It very much depends on the usecase. > > If you have a laptop and you're trying to give a presentation, > applying dithering and/or DSC makes a lot of sense: you don't want > your battery to die, and the projector's probably going to obliterate > half the colour anyway, so might as well as go for the most efficient > thing. BTW DSC is not free. The compressor does actual work, which takes energy. DSC may be a win power wise if you can then reduce the link frequency (+ some internal voltages/etc.). But if you can't reduce anything then all you really end up doing is burning more power compressing things needlessly. But it's all very hardware specific of course. So having explicit userspace control for this stuff doesn't seem like the best idea, apart from maybe a "no DSC at all" knob for the people who can't tolerate any kind of compression artifacts. I've been musing about userspace being able to provide some kind of relative quality weights for each output. The driver could then use those to figure out how to balance the final bpc and compression between the outputs. Something like this would let userspace express its preference while still allowing the driver to decide how to actually get there. Simple 'desired bpc' seem somewhat insufficient because I would imagine userspace just sets that to max for everything at the start, so the driver might not be able to tell which outputs can be degraded harder than others. I suppose a desired+min bpc might work, but would potentially force userspace to tweak the parameters in some semi random fashion and try again if the end result isn't appealing. And exactly what to tweak is really hard for userspace to figure out since it has no idea of the possibly complex internal/tbt/mst topologies, power costs, etc. > If your laptop is plugged into your big display at home to write code, > applying DSC to cram the highest possible resolution + refresh in > would make sense. But if dithering only results in a marginal power > saving, and your laptop is charging anyway - why bother degrading > visual acuity? > > If you're a media player, then you're in a good position to know what > would be good to go over the wire, because you know (& are possibly in > control of) the format over what comes in in the first place. > > But everyone's tradeoffs are different, which is why sometimes the > best choice is to ultimately leave it up to the user. If you dig into > any media playback device (STBs running Android TV, Apple TV, Fire TV, > et al), you'll see that all of them ultimately allow overrides for bpc > / colour model / subsampling / etc. Those aren't just there for fun, > but because they are usable to real people, and it's not possible for > Amlogic or MediaTek or Rockchip or whoever to statically decide that a > certain configuration is going to be best everywhere. > > Right now we have drivers making magic per-vendor/SKU decisions, > without even so much as a feedback mechanism to userspace (unless you > count debugfs, maybe) so it can even figure out what's going on, let > alone control it. To properly support some of those usecases, > userspace needs to be able to control what goes out on the wire, but > as a first step, it just wants to be informed of what the driver even > did with the properties we gave it. > > The end game of this isn't Weston logging something to stdout, it's to > surface things to userspace so it can guide the kernel into making a > good decision for usecases that may not be ones the silicon vendor > decided was 'probably the best thing' however many years ago. > > Cheers, > Daniel -- Ville Syrjälä Intel
On Wed, 1 Apr 2026 at 14:58, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > I've been musing about userspace being able to provide some kind of > relative quality weights for each output. The driver could then use > those to figure out how to balance the final bpc and compression > between the outputs. Something like this would let userspace express > its preference while still allowing the driver to decide how to > actually get there. > > Simple 'desired bpc' seem somewhat insufficient because I would > imagine userspace just sets that to max for everything at the start, > so the driver might not be able to tell which outputs can be degraded > harder than others. > > I suppose a desired+min bpc might work, but would potentially force > userspace to tweak the parameters in some semi random fashion and > try again if the end result isn't appealing. And exactly what to > tweak is really hard for userspace to figure out since it has no > idea of the possibly complex internal/tbt/mst topologies, power > costs, etc. I agree with everything you've written, apart from 'I would imagine userspace just sets that to max for everything at the start'. I've taken it as axiomatic that all of these things should have an 'auto' value, and have it as their default setting. Userspace _may_ know better than the IHV, but it's only going to know on a situational basis. Compositors blindly setting random tuneables to MAX_AWESOME_POWER would be just as stupid as distros shipping ye olde Option "AGPFastWrite" and Option "AGPMode" "8" by default. I'd expect any userspace which blindly did that to immediately get as many bug reports as they have users, and for them to fix it accordingly. By analogy, we allow userspace to ignore EDID and set whatever cool awesome mode it wants to. But it doesn't do that unless it has a very very good reason to override the driver, and 99 times out of 100, that reason is 'the user has figured out that this is required'. Does that help? Cheers, Daniel
On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote: > Hi Harry, > > On Tue, 31 Mar 2026 at 18:47, Harry Wentland <harry.wentland@amd.com> wrote: > > On 2026-03-31 08:50, Pekka Paalanen wrote: > > > People who care about the picture quality down to these levels will > > > likely want to know and learn about these techniques. They may also > > > want to explicitly control them. > > > > > > In time, when these have been used enough in the wild, compositor > > > developers will learn what makes a difference and what does not, so > > > they will adjust their reporting to end users. The most important thing > > > for the kernel is it offer an unambiguous and stable UAPI for these. > > > > > > Policy belongs in userspace. > > > > I don't like this as a blanket statement. There is a lot of policy that > > intersects with HW nuances, whether it comes to power or otherwise. > > Taking away driver vendor's abilities to optimize will hurt the Linux > > ecosystem in the long run. > > > > IMO this needs to be evaluated on a case by case basis. There are > > many places where it does make sense to give userspace a greater > > say on policy, but we don't want to push driver (HW specific) logic > > up into userspace. > > It's not something that's _just_ specific to a particular > display-controller manufacturer or a particular IP generation though. > It very much depends on the usecase. > > If you have a laptop and you're trying to give a presentation, > applying dithering and/or DSC makes a lot of sense: you don't want > your battery to die, and the projector's probably going to obliterate > half the colour anyway, so might as well as go for the most efficient > thing. > > If your laptop is plugged into your big display at home to write code, > applying DSC to cram the highest possible resolution + refresh in > would make sense. But if dithering only results in a marginal power > saving, and your laptop is charging anyway - why bother degrading > visual acuity? > > If you're a media player, then you're in a good position to know what > would be good to go over the wire, because you know (& are possibly in > control of) the format over what comes in in the first place. > > But everyone's tradeoffs are different, which is why sometimes the > best choice is to ultimately leave it up to the user. If you dig into > any media playback device (STBs running Android TV, Apple TV, Fire TV, > et al), you'll see that all of them ultimately allow overrides for bpc > / colour model / subsampling / etc. Those aren't just there for fun, > but because they are usable to real people, and it's not possible for > Amlogic or MediaTek or Rockchip or whoever to statically decide that a > certain configuration is going to be best everywhere. > > Right now we have drivers making magic per-vendor/SKU decisions, > without even so much as a feedback mechanism to userspace (unless you > count debugfs, maybe) so it can even figure out what's going on, let > alone control it. To properly support some of those usecases, > userspace needs to be able to control what goes out on the wire, but > as a first step, it just wants to be informed of what the driver even > did with the properties we gave it. > > The end game of this isn't Weston logging something to stdout, it's to > surface things to userspace so it can guide the kernel into making a > good decision for usecases that may not be ones the silicon vendor > decided was 'probably the best thing' however many years ago. I think the problem here is that no one even tried to make a real userspace implementation. So it's very hard to judge if this new property is actually usable in the end, or if it will just end up as historical baggage that we have to carry around forever. IMO just having userspace log what the kernel said does not fulfill the "userspace implementation must be ready before new drm uapi is merged" requirement. -- Ville Syrjälä Intel
Hi, On Wed, 1 Apr 2026 at 12:10, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Wed, Apr 01, 2026 at 09:40:15AM +0100, Daniel Stone wrote: > > The end game of this isn't Weston logging something to stdout, it's to > > surface things to userspace so it can guide the kernel into making a > > good decision for usecases that may not be ones the silicon vendor > > decided was 'probably the best thing' however many years ago. > > I think the problem here is that no one even tried to make a > real userspace implementation. So it's very hard to judge if this > new property is actually usable in the end, or if it will just end > up as historical baggage that we have to carry around forever. > > IMO just having userspace log what the kernel said does not fulfill > the "userspace implementation must be ready before new drm uapi is > merged" requirement. Sure. To be honest it seemed pretty obviously reflective of 'max bpc'. Derek is working on a Weston implementation which uses 'link bpc' as part of a control loop with 'max bpc' now, which should hopefully satisfy that. Cheers, Daniel
© 2016 - 2026 Red Hat, Inc.