On Wed, 15 Feb 2023 17:03:54 +0000
Simon Ser <contact@xxxxxxxxxxx> wrote:
> On Wednesday, February 15th, 2023 at 14:41, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
>
> > 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?
>
> drm_gem_prime_fd_to_handle() explicitly checks whether the memory object
> already has a GEM handle via drm_prime_lookup_buf_handle(). OTOH,
> drm_mode_getfb() and drm_mode_getfb2_ioctl() just unconditionally call
> drm_gem_handle_create().
>
> Yes, it's a rather inconsistent detail. A detail which becomes very
> important when ref'counting and trying not to leak GEM handles from
> user-space. Fortunately GETFB/GETFB2 usage is pretty seldom.
I see that GETFB was introduced in
commit f453ba0460742ad027ae0c4c7d61e62817b3e7ef
Author: Dave Airlie <airlied@xxxxxxxxxx>
Date: Fri Nov 7 14:05:41 2008 -0800
DRM: add mode setting support
and I guess GETFB2 just replicated the behaviour for no reason. Was
that it, Daniel S.? Are there other pitfalls that should be documented?
So it was long before dmabuf was a thing I believe, meaning that any
dmabuf import problems could not have been known.
Btw. does this also mean that if you use GETFB2 to get handle A, you
export that as dmabuf and import in the same open device instance, you
again get handle A?
IOW, you should *never* ever export a dmabuf of what you got with
GETFB2. If one did, one might import it oneself via GBM, breaking all
reference counting. But you also cannot "just leak" the handle A,
because if GBM happens to run on a different DRM device opened
instance, GBM would get a different handle to own.
That's... err. How is a compositor supposed to do transition animation
from an old FB to its own thing? I guess mmap + glTexImage2D equivalent
to make a copy of the old FB so one can use it as a texture?
Maybe something about this would be good to spell out in the doc?
Thanks,
pq
Attachment:
pgp4K13kXEg9Y.pgp
Description: OpenPGP digital signature
