Documentation/gpu/drm-uapi.rst

7 The DRM core exports several interfaces to applications, generally
28 Primary Nodes, DRM Master and Authentication
43 The DRM subsystem has stricter requirements than most other kernel subsystems on
47 The short summary is that any addition of DRM uAPI requires corresponding
67   open-source userspace of the DRM subsystem. DRM developers are perfectly fine
108 is already rather painful for the DRM subsystem, with multiple different uAPIs
117 DRM core provides multiple character-devices for user-space to use.
129 make use of a GPU. But the DRM API required unprivileged clients to
130 authenticate to a DRM-Master prior to getting GPU access. To avoid this
135 render nodes, it must advertise it via the DRIVER_RENDER DRM driver
139 If a driver advertises render node support, DRM core will create a
159 DRM-Master concept. There is no reason to associate render clients with
160 a DRM-Master as they are independent of any graphics server. Besides,
178 damage from hot-unplugging a DRM device needs to be limited as much as
180 to. Ideally, unplugging a DRM device still lets a desktop continue to
190 working more or less, until userspace stops using the disappeared DRM
196 Only after userspace has closed all relevant DRM device and dmabuf file
197 descriptors and removed all mmaps, the DRM driver can tear down its
199 device somehow comes back in the mean time, it shall be a new DRM
203 new DRM device always picks the next free minor number compared to the
219 - Pending non-blocking KMS operations deliver the DRM events userspace
225 - Attempting to create a DRM lease on a disappeared DRM device will
226   fail with ENODEV. Existing DRM leases remain and work as listed
238   VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
290 practice within the DRM subsystem:
309         E.g. root-only or much more common, DRM master-only operations return
325         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
340 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
341 "this IOCTL does not exist", and is used exactly as such in DRM.
367 DRM drivers and that can be used to check that changes to DRM drivers or the
372 Using VKMS to test DRM API
378 a perfect tool for validating the DRM core behavior and also support the
379 compositor developer. VKMS makes it possible to test DRM functions in a
383 To Validate changes in DRM API with VKMS, start setting the kernel: make
440 The DRM core exposes two vertical blank related ioctls: