STRUCT DRM_DRIVER(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME

okay so this is the manual page for struct drm_driver(9) β€” literally the DRM driver structure, bestie. it's giving "the blueprint for how a DRM driver family does its thing." let's get into it. πŸŽ€

πŸŽ€ SYNOPSIS

struct drm_driver {
    int (*load) (struct drm_device *, unsigned long flags);
    int (*open) (struct drm_device *, struct drm_file *);
    void (*postclose) (struct drm_device *, struct drm_file *);
    void (*unload) (struct drm_device *);
    void (*release) (struct drm_device *);
    void (*master_set)(struct drm_device *dev, struct drm_file
*file_priv, bool from_open);
    void (*master_drop)(struct drm_device *dev, struct drm_file
*file_priv);
    void (*debugfs_init)(struct drm_minor *minor);
    struct drm_gem_object *(*gem_create_object)(struct drm_device *dev,
size_t size);
    int (*prime_handle_to_fd)(struct drm_device *dev, struct drm_file
*file_priv, uint32_t handle, uint32_t flags, int *prime_fd);
    int (*prime_fd_to_handle)(struct drm_device *dev, struct drm_file
*file_priv, int prime_fd, uint32_t *handle);
    struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
struct dma_buf *dma_buf);
    struct drm_gem_object *(*gem_prime_import_sg_table)( struct
drm_device *dev, struct dma_buf_attachment *attach, struct sg_table
*sgt);
    int (*dumb_create)(struct drm_file *file_priv, struct drm_device
*dev, struct drm_mode_create_dumb *args);
    int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device
*dev, uint32_t handle, uint64_t *offset);
    int (*fbdev_probe)(struct drm_fb_helper *fbdev_helper, struct
drm_fb_helper_surface_size *sizes);
    void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
    int major;
    int minor;
    int patchlevel;
    char *name;
    char *desc;
    u32 driver_features;
    const struct drm_ioctl_desc *ioctls;
    int num_ioctls;
    const struct file_operations *fops;
 };

✨ Members ✨

  • load β€” okay so this is the backward-compatible driver callback to complete initialization steps after the driver is registered. but bestie, for this reason it may suffer from race conditions, and its use is deprecated for new drivers. it's therefore only supported for existing drivers not yet converted to the new scheme. see devm_drm_dev_alloc and drm_dev_register for the proper and race-free way to set up a struct drm_device. and literally: this is deprecated, do not use! returns: zero on success, non-zero value on failure. periodt. πŸ’…
  • open β€” this is the driver callback when a new struct drm_file is opened. useful for setting up driver-private data structures like buffer allocators, execution contexts, or similar things. such driver-private resources must be released again in postclose. since the display/modeset side of DRM can only be owned by exactly one struct drm_file (see drm_file.is_master and drm_device.master), there should never be a need to set up any modeset related resources in this callback. doing so would be a driver design bug, no cap. returns: 0 on success, a negative error code on failure, which will be promoted to userspace as the result of the open system call. πŸ¦‹
  • postclose β€” one of the driver callbacks when a new struct drm_file is closed. useful for tearing down driver-private data structures allocated in open like buffer allocators, execution contexts, or similar things. same vibe as open: since the display/modeset side of DRM can only be owned by exactly one struct drm_file (see drm_file.is_master and drm_device.master), there should never be a need to tear down any modeset related resources in this callback. doing so would be a driver design bug. 🌸
  • unload β€” reverse the effects of the driver load callback. ideally, the clean up performed by the driver should happen in the reverse order of the initialization. similarly to the load hook, this handler is deprecated and its usage should be dropped in favor of an open-coded teardown function at the driver layer. see drm_dev_unregister and drm_dev_put for the proper way to remove a struct drm_device. the unload hook is called right after unregistering the device. πŸ’€
  • release β€” optional callback for destroying device data after the final reference is released, i.e. the device is being destroyed. this is deprecated β€” clean up all memory allocations associated with a drm_device using drmm_add_action, drmm_kmalloc and related managed resources functions. πŸ™ˆ
  • master_set β€” called whenever the minor master is set. only used by vmwgfx. πŸ‘‘
  • master_drop β€” called whenever the minor master is dropped. only used by vmwgfx. πŸ‘‘
  • debugfs_init β€” allows drivers to create driver-specific debugfs files. ✨
  • gem_create_object β€” constructor for gem objects. hook for allocating the GEM object struct, for use by the CMA and SHMEM GEM helpers. returns a GEM object on success, or an ERR_PTR-encoded error code otherwise. πŸ”₯
  • prime_handle_to_fd β€” PRIME export function. only used by vmwgfx. 🌈
  • prime_fd_to_handle β€” PRIME import function. only used by vmwgfx. 🌈
  • gem_prime_import β€” import hook for GEM drivers. this defaults to drm_gem_prime_import if not set. ⭐
  • gem_prime_import_sg_table β€” optional hook used by the PRIME helper functions drm_gem_prime_import respectively drm_gem_prime_import_dev. ⭐
  • dumb_create β€” this creates a new dumb buffer in the driver's backing storage manager (GEM, TTM or something else entirely) and returns the resulting buffer handle. this handle can then be wrapped up into a framebuffer modeset object. note that userspace is not allowed to use such objects for render acceleration β€” drivers must create their own private ioctls for such a use case. width, height and depth are specified in the drm_mode_create_dumb argument. the callback needs to fill the handle, pitch and size for the created buffer. called by the user via ioctl. returns: zero on success, negative errno on failure. πŸ“
  • dumb_map_offset β€” allocate an offset in the drm device node's address space to be able to memory map a dumb buffer. the default implementation is drm_gem_create_mmap_offset. GEM based drivers must not overwrite this. called by the user via ioctl. returns: zero on success, negative errno on failure. πŸ“
  • fbdev_probe β€” allocates and initialize the fb_info structure for fbdev emulation. furthermore it also needs to allocate the DRM framebuffer used to back the fbdev. this callback is mandatory for fbdev support. returns: 0 on success ot a negative error code otherwise. (yes, it says "ot" in the original, slay typo 😭) 🧚
  • show_fdinfo β€” print device specific fdinfo. see Documentation/gpu/drm-usage-stats.rst. πŸ’œ
  • major β€” driver major number. πŸ”’
  • minor β€” driver minor number. πŸ”’
  • patchlevel β€” driver patch level. πŸ”’
  • name β€” driver name. 🏷️
  • desc β€” driver description. πŸ“
  • driver_features β€” driver features, see enum drm_driver_feature. drivers can disable some features on a per-instance basis using drm_device.driver_features. πŸŽ›οΈ
  • ioctls β€” array of driver-private IOCTL description entries. see the chapter on :ref:IOCTL support in the userland interfaces chapter<drm_driver_ioctl> for the full details. πŸ“š
  • num_ioctls β€” number of entries in ioctls. πŸ”’
  • fops β€” file operations for the DRM device node. see the discussion in :ref:file operations<drm_driver_fops> for in-depth coverage and some examples. πŸ“‚

🌸 Description

this structure represent the common code for a family of cards. there will be one struct drm_device for each card present in this family. it contains lots of vfunc entries, and a pile of those probably should be moved to more appropriate places like drm_mode_config_funcs or into a new operations structure for GEM drivers. it's giving "we know it's a bit messy, but it works." πŸ’–

🌈 SEE ALSO


k bye bestie, this iconic page is from ./include/drm, dated October 2026, and it's literally the struct drm_driver(9) manual. slay. πŸ’…πŸŽ€βœ¨

πŸ“¦ where this page comes from