Lines Matching refs:DRM

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
301 practice within the DRM subsystem:
320         E.g. root-only or much more common, DRM master-only operations return
336         DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
351 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
352 "this IOCTL does not exist", and is used exactly as such in DRM.
378 DRM drivers and that can be used to check that changes to DRM drivers or the
383 Using VKMS to test DRM API
389 a perfect tool for validating the DRM core behavior and also support the
390 compositor developer. VKMS makes it possible to test DRM functions in a
394 To Validate changes in DRM API with VKMS, start setting the kernel: make
451 The DRM core exposes two vertical blank related ioctls: