Re: [PATCH v5 0/3] Add "link bpc" DRM property
On 4/1/26 14:14, Nicolas Frattaroli wrote: > On Wednesday, 1 April 2026 13:57:08 Central European Summer Time Xaver Hugl > wrote: >> Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli >> : >>> >>> 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. > > To do this I'd need to see if there's some feedback mechanism for > the output configuration chosen by the atomic check phase, so that > userspace can then run a DRM_MODE_ATOMIC_TEST_ONLY and get the value > back somehow. > > The current implementation wouldn't be able to do this since it > updates the property on commit_tail. I'll need to look into whether > drivers already have everything figured out with regards to link bpc > in the check phase, and how that would best be communicated to > userspace. Taking both the Weston use case described in this thread and Xaver's requirements into account, a "min bpc" property complementing the "max bpc" one (as suggested by Ville before) might be better than "link bpc". That might be a better fit even just for the Weston use case described in this thread, since AFAICT that only really cares about the minimum bpc, not the maximum. The compositor could set "min bpc" to any value <= the "max bpc" one. If the driver can't make things work with effective bpc >= "min bpc", the commit fails. Setting both properties to the same value would allow selecting a specific bpc. That would allow compositors to find possible bpc permutations using TEST_ONLY commits, as described by Xaver. Setting "min bpc" to 0 (which should probably be the default value) would allow any bpc, i.e. "auto" behaviour. One potential issue with the "min bpc" property is that if one DRM master leaves it at a non-0 value, and a later DRM master doesn't know about it yet, it might cause surprising commit failures for the latter. This kind of issue already exists with other properties though. (Some kind of "default state" mechanism might help for solving this kind of issue) -- Earthling Michel Dänzer \GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
Re: [PATCH v5 0/3] Add "link bpc" DRM property
On Wed, Apr 01, 2026 at 01:25:31PM +0100, Daniel Stone wrote: > On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä > 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
Re: [PATCH v5 0/3] Add "link bpc" DRM property
On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä 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
Re: [PATCH v5 0/3] Add "link bpc" DRM property
On Wednesday, 1 April 2026 13:57:08 Central European Summer Time Xaver Hugl wrote: > Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli > : > > > > 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. To do this I'd need to see if there's some feedback mechanism for the output configuration chosen by the atomic check phase, so that userspace can then run a DRM_MODE_ATOMIC_TEST_ONLY and get the value back somehow. The current implementation wouldn't be able to do this since it updates the property on commit_tail. I'll need to look into whether drivers already have everything figured out with regards to link bpc in the check phase, and how that would best be communicated to userspace. > 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. I'll do that, but consider using lei[1] to have saved searches on lore delivered to a local Mailbox, a suitable query here may be dfb:drm_property which will return all e-mails with diffs matching added lines with "drm_property" in them, from which lei can then fetch the full threads. > > - Xaver > Kind regards, Nicolas Frattaroli https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started [1]
Re: [PATCH v5 0/3] Add "link bpc" DRM property
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 > : > > > > 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
Re: [PATCH v5 0/3] Add "link bpc" DRM property
Am Do., 19. März 2026 um 13:28 Uhr schrieb Nicolas Frattaroli : > > 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
