Lines Matching refs:DRM
5 The DRM core exports several interfaces to applications, generally
26 Primary Nodes, DRM Master and Authentication
41 The DRM subsystem has stricter requirements than most other kernel subsystems on
45 The short summary is that any addition of DRM uAPI requires corresponding
65 open-source userspace of the DRM subsystem. DRM developers are perfectly fine
106 is already rather painful for the DRM subsystem, with multiple different uAPIs
115 DRM core provides multiple character-devices for user-space to use.
127 make use of a GPU. But the DRM API required unprivileged clients to
128 authenticate to a DRM-Master prior to getting GPU access. To avoid this
133 render nodes, it must advertise it via the DRIVER_RENDER DRM driver
137 If a driver advertises render node support, DRM core will create a
157 DRM-Master concept. There is no reason to associate render clients with
158 a DRM-Master as they are independent of any graphics server. Besides,
178 practice within the DRM subsystem:
197 E.g. root-only or much more common, DRM master-only operations return
213 DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
228 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
229 "this IOCTL does not exist", and is used exactly as such in DRM.
255 DRM drivers and that can be used to check that changes to DRM drivers or the
319 The DRM core exposes two vertical blank related ioctls: