Documentation/gpu/drm-uapi.rst

7 The DRM core exports several interfaces to applications, generally
28 Primary Nodes, DRM Master and Authentication
43 DRM Display Resource Leasing
52 The DRM subsystem has stricter requirements than most other kernel subsystems on
56 The short summary is that any addition of DRM uAPI requires corresponding
76   open-source userspace of the DRM subsystem. DRM developers are perfectly fine
117 is already rather painful for the DRM subsystem, with multiple different uAPIs
126 DRM core provides multiple character-devices for user-space to use.
138 make use of a GPU. But the DRM API required unprivileged clients to
139 authenticate to a DRM-Master prior to getting GPU access. To avoid this
144 render nodes, it must advertise it via the DRIVER_RENDER DRM driver
148 If a driver advertises render node support, DRM core will create a
170 DRM-Master concept. There is no reason to associate render clients with
171 a DRM-Master as they are independent of any graphics server. Besides,
189 damage from hot-unplugging a DRM device needs to be limited as much as
191 to. Ideally, unplugging a DRM device still lets a desktop continue to
201 working more or less, until userspace stops using the disappeared DRM
207 Only after userspace has closed all relevant DRM device and dmabuf file
208 descriptors and removed all mmaps, the DRM driver can tear down its
210 device somehow comes back in the mean time, it shall be a new DRM
214 new DRM device always picks the next free minor number compared to the
230 - Pending non-blocking KMS operations deliver the DRM events userspace
236 - Attempting to create a DRM lease on a disappeared DRM device will
237   fail with ENODEV. Existing DRM leases remain and work as listed
249   VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
294 section describes the expectations for DRM and usermode drivers when a
312 driver separately, with no common DRM interface. Ideally this should be properly
313 integrated at DRM scheduler to provide a common ground for all drivers. After a
361 the first place. DRM devices should make use of devcoredump to store relevant
378 practice within the DRM subsystem:
397         E.g. root-only or much more common, DRM master-only operations return
413         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
428 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
429 "this IOCTL does not exist", and is used exactly as such in DRM.
455 DRM drivers and that can be used to check that changes to DRM drivers or the
460 Using VKMS to test DRM API
466 a perfect tool for validating the DRM core behavior and also support the
467 compositor developer. VKMS makes it possible to test DRM functions in a
471 To Validate changes in DRM API with VKMS, start setting the kernel: make
528 The DRM core exposes two vertical blank related ioctls:
572 information on how dma-buf is integrated and exposed within DRM.