[PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace

[Andri Yngvason]

Hi Daniel,

þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone <daniel at fooishbar.org>:

> On Tue, 9 Jan 2024 at 18:12, Andri Yngvason <andri at yngvason.is> wrote:
> > + * active color format:
> > + *     This read-only property tells userspace the color format
> actually used
> > + *     by the hardware display engine "on the cable" on a connector.
> The chosen
> > + *     value depends on hardware capabilities, both display engine and
> > + *     connected monitor. Drivers shall use
> > + *     drm_connector_attach_active_color_format_property() to install
> this
> > + *     property. Possible values are "not applicable", "rgb",
> "ycbcr444",
> > + *     "ycbcr422", and "ycbcr420".
>
> How does userspace determine what's happened without polling? Will it
> only change after an `ALLOW_MODESET` commit, and be guaranteed to be
> updated after the commit has completed and the event being sent?
> Should it send a HOTPLUG event? Other?
>

Userspace does not determine what's happened without polling. The purpose
of this property is not for programmatic verification that the preferred
property was applied. It is my understanding that it's mostly intended for
debugging purposes. It should only change as a consequence of modesetting,
although I didn't actually look into what happens if you set the "preferred
color format" outside of a modeset.

The way I've implemented things in sway, calling the
"preferred_signal_format" command triggers a modeset with the "preferred
color format" set and calling "get_outputs", immediately queries the
"actual color format" and displays it.

Regards,
Andri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20240109/4cda8a15/attachment-0001.htm>