This is a bit tricky, because of the ref'counting considerations. See also [1] for more discussion about this topic. Since this is kernel docs, I've decided to elaborate a bit less on the user-space details. [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
Showing the changes to include/uapi/drm (1 of 1 file). Show all
Unified · Split
| @@ -972,6 +972,19 @@ extern "C" { · 971 unmodified lines | ||
| 972 | 972 | #define DRM_IOCTL_GET_STATS DRM_IOR( 0x06, struct drm_stats) |
| 973 | 973 | #define DRM_IOCTL_SET_VERSION DRM_IOWR(0x07, struct drm_set_version) |
| 974 | 974 | #define DRM_IOCTL_MODESET_CTL DRM_IOW(0x08, struct drm_modeset_ctl) |
| 975 | +/** | |
| 976 | + * DRM_IOCTL_GEM_CLOSE - Close a GEM handle. | |
| 977 | + * | |
| 978 | + * GEM handles are not reference-counted by the kernel. User-space is | |
| 979 | + * responsible for managing their lifetime. For example, if user-space imports | |
| 980 | + * the same memory object twice on the same DRM file description, the same GEM | |
| 981 | + * handle is returned by both imports, and user-space needs to ensure | |
| 982 | + * &DRM_IOCTL_GEM_CLOSE is performed once only. The same situation can happen | |
| 983 | + * when a memory object is allocated, then exported and imported again on the | |
| 984 | + * same DRM file description. The &DRM_IOCTL_MODE_GETFB2 IOCTL is an exception | |
| 985 | + * and always returns fresh new GEM handles even if an existing GEM handle | |
| 986 | + * already refers to the same memory object before the IOCTL is performed. | |
| 987 | + */ | |
| 975 | 988 | #define DRM_IOCTL_GEM_CLOSE DRM_IOW (0x09, struct drm_gem_close) |
| 976 | 989 | #define DRM_IOCTL_GEM_FLINK DRM_IOWR(0x0a, struct drm_gem_flink) |
| 977 | 990 | #define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open) |