On Fri, Nov 8, 2013 at 11:02 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: > It seems like prime_handle_from_fd needs to be paired with a GEM_CLOSE ioctl > instead of a new generic HANDLE_CLOSE ioctl. > > This oversight is not really a big problem but there are two solutions: > 1) Create a new ioctl called HANDLE_CLOSE or something similar. > 2) Use the GEM_CLOSE ioctl, but add a driver callback for drivers that are > not GEM-aware. > > It seems like GEM_CLOSE has already spread into user-space clients, so > unless someone tell me otherwise, I'll be using > 2) for the vmwgfx prime implementation. Oops, I didn't really realize when fixing the prime lifetime stuff that vmwgfx doesn't use gem handles for it's buffers. What about 3) Move drm_gem_remove_prime_handles to drm_prime.c, expose it to modules and use that in the vmwgfx handle close ioctl? Imo GEM_CLOSE shouldn't ever be called by generic code in userspace, so if that's already broken it should be fixed in userspace not papered over in the kernel by partially faking gem on vmwgfx. I just fear that if we start doing that we need to virtualize more of the few gem bits, which renders the point of gem being optional moot. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
