Re: [PATCH v5 0/3] Add "link bpc" DRM property
From: Nicolas Frattaroli
Date: Wed Apr 01 2026 - 08:28:06 EST
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
> <nicolas.frattaroli@xxxxxxxxxxxxx>:
> >
> > 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]