DE/compositor development notes - DRM operations - resource sharing
Graphics hardware might need to be shared by the compositor and applications.
Compositor is in charge of display controller as a final arbiter of what goes to screen (except leasing, see below), but applications need access to rendering functionality. Several compositors need to share hardware too.
Giving application access to the rendering
Application (actually, usually Mesa on behalf of application) opens rendering device node, uses it for rendering. Easy1.
Sharing a display controller between compositors
There is a concept of “DRM master”: an application that owns the display controller functionality in DRM. First process that opens DRM card device becomes master automatically.
Whenever a compositor needs to yield access to display controller to another compositor,
DRM_IOCTL_DROP_MASTER. Whenever it needs to become a master again, it
This dance is typically performed in VT switch sequence.
Handing over the display controller to the application
Sometimes an application needs full control over a display controller. Typically it happens when a display controller is a part of specialized device, such as VR hardware. In this case compositor may lease a DRM device to an application.
DRM_IOCTL_MODE_CREATE_LEASE with a set of DRM objects it wants to
lease, gets back a new DRM file descriptor and passes it to the application.
Compositor may list the active leases with
DRM_IOCTL_LIST_LESSEES, leased objects
DRM_IOCTL_GET_LEASE and yank control back at any time using
Application can use new file descriptor as if it is a real DRM master.
This used to be much more complicated. Before rendering devices were introduced, applications opened card devices, used
DRM_IOCTL_GET_MAGICto obtain a magic cookie, passed it to the compositor that used
DRM_IOCTL_AUTH_MAGICto allow applications to render. ↩︎