[PATCH] drm: document expectations for GETFB2 handles

[Pekka Paalanen]

On Wed, 15 Feb 2023 12:42:00 +0000
Simon Ser <contact at emersion.fr> wrote:

> There are two important details missing from the docs:
> 
> - If the memory object backing the FB already has a GEM handle,
>   it's not re-used, a new one is generated.
> - Aliased planes will return the same GEM handle.
> 
> Signed-off-by: Simon Ser <contact at emersion.fr>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Pekka Paalanen <ppaalanen at gmail.com>
> ---
>  include/uapi/drm/drm.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 642808520d92..4cb956a52aee 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -1104,8 +1104,13 @@ extern "C" {
>   * struct as the output.
>   *
>   * If the client is DRM master or has &CAP_SYS_ADMIN, &drm_mode_fb_cmd2.handles
> - * will be filled with GEM buffer handles. Planes are valid until one has a
> - * zero handle -- this can be used to compute the number of planes.
> + * will be filled with GEM buffer handles. Fresh new GEM handles are always
> + * returned, even if another GEM handle referring to the same memory object
> + * already exists on the DRM file description. The caller is responsible for
> + * removing the new handles, e.g. via the &DRM_IOCTL_GEM_CLOSE IOCTL. The same
> + * new handle will be returned for multiple planes in case they use the same
> + * memory object. Planes are valid until one has a zero handle -- this can be
> + * used to compute the number of planes.
>   *
>   * Otherwise, &drm_mode_fb_cmd2.handles will be zeroed and planes are valid
>   * until one has a zero &drm_mode_fb_cmd2.pitches.

It is well-written, clear, and a surprise to me.

Acked-by: Pekka Paalanen <pekka.paalanen at collabora.com>

I didn't know it was at all possible to have different GEM handles
pointing to the same object. DMABUF import is guaranteed to return the
existing GEM handle, right? Why is GETFB2 different? Why does it not
have the same problem as what forced DMABUF import to return existing
handles?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230215/89cdb06d/attachment.sig>