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
104 is already rather painful for the DRM subsystem, with multiple different uAPIs
113 DRM core provides multiple character-devices for user-space to use.
125 make use of a GPU. But the DRM API required unprivileged clients to
126 authenticate to a DRM-Master prior to getting GPU access. To avoid this
131 render nodes, it must advertise it via the DRIVER_RENDER DRM driver
135 If a driver advertises render node support, DRM core will create a
155 DRM-Master concept. There is no reason to associate render clients with
156 a DRM-Master as they are independent of any graphics server. Besides,
176 practice within the DRM subsystem:
195 E.g. root-only or much more common, DRM master-only operations return
208 DRM drivers assume that userspace restarts all IOCTLs. Any DRM IOCTL can
223 DRM specific patterns. Note that ENOTTY has the slightly unintuitive meaning of
224 "this IOCTL does not exist", and is used exactly as such in DRM.
242 DRM drivers and that can be used to check that changes to DRM drivers or the
306 The DRM core exposes two vertical blank related ioctls: