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
168 DRM-Master concept. There is no reason to associate render clients with
169 a DRM-Master as they are independent of any graphics server. Besides,
187 damage from hot-unplugging a DRM device needs to be limited as much as
189 to. Ideally, unplugging a DRM device still lets a desktop continue to
199 working more or less, until userspace stops using the disappeared DRM
205 Only after userspace has closed all relevant DRM device and dmabuf file
206 descriptors and removed all mmaps, the DRM driver can tear down its
208 device somehow comes back in the mean time, it shall be a new DRM
212 new DRM device always picks the next free minor number compared to the
228 - Pending non-blocking KMS operations deliver the DRM events userspace
234 - Attempting to create a DRM lease on a disappeared DRM device will
235 fail with ENODEV. Existing DRM leases remain and work as listed
247 VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
299 practice within the DRM subsystem:
318 E.g. root-only or much more common, DRM master-only operations return
334 DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
349 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
350 "this IOCTL does not exist", and is used exactly as such in DRM.
376 DRM drivers and that can be used to check that changes to DRM drivers or the
381 Using VKMS to test DRM API
387 a perfect tool for validating the DRM core behavior and also support the
388 compositor developer. VKMS makes it possible to test DRM functions in a
392 To Validate changes in DRM API with VKMS, start setting the kernel: make
449 The DRM core exposes two vertical blank related ioctls: