Initial KMS transactional support
This is the first part of transactional KMS support. In short, it adds designed-to-be thread safe KMS building blocks APIs, and a transaction API, but only a legacy drmMode* using implementation. It doesn't port all usage yet; the rest is yet to be completed.
To avoid duplication, here is the copy pasted documentation added in the last commit:
SECTION:kms
@short description: KMS abstraction
@title: KMS abstraction
The KMS abstraction consists of various building blocks for helping out with
interacting with the various drm API's, enabling users to use a
transactional API, aiming to hide all interaction with the underlying APIs.
The subsystem defines two separate contexts, the "main" context, and the
"impl" context. The main context is the context of which mutter as a whole
runs in. It uses the main GLib main loop and main context and always runs in
the main thread.
The impl context is where all underlying API is being executed. While in the
current state, it always runs in the main thread, the aim is to be able to
execute the impl context in a dedicated thread.
The public facing MetaKms API is always assumed to be executed from the main
context.
The KMS abstraction consists of the following public components:
#MetaKms:
Main entry point; used by the native backend to create devices, post updates
etc.
#MetaKmsDevice:
A device (usually /dev/dri/cardN, where N being a number). Used to get KMS
objects, such as connectors, CRTCs, planes, as well as basic meta data such
as device path etc.
#MetaKmsCrtc:
Represents a CRTC. It manages a representation of the current CRTC state,
including current mode, coordinates, possible clones.
#MetaKmsConnector:
Represents a connector, e.g. a display port connection. It also manages a
representation of the current state, including meta data such as physical
dimension of the connected, available modes, EDID, tile info etc. It also
contains helper functions for configuration, as well as methods for adding
configuration to a transaction (See #MetaKmsUpdate).
#MetaKmsPlane:
Represents a hardware plane. A plane is used to define the content of what
should be presented on a CRTC. Planes can either be primary planes, used as
a backdrop for CRTCs, overlay planes, and cursor planes.
#MetaKmsUpdate:
A KMS transaction object, meant to be processed potentially atomically when
posted. An update consists of plane assignments, mode sets and KMS object
property entries. The user adds updates to the object, and then posts it via
MetaKms. It will then be processed by the MetaKms backend (See
#MetaKmsImpl), potentially atomically.
There are also these private objects, without public facing API:
#MetaKmsImpl:
The KMS backend implementation, running in the impl context. #MetaKmsImpl
itself is an abstract object, with potentially multiple implementations.
Currently only #MetaKmsImplSimple exists.
#MetaKmsImplSimple:
A KMS backend implementation using the non-atomic drmMode* API. While it's
interacted with using the transactional API, the #MetaKmsUpdate is processed
non-atomically.
#MetaKmsImplDevice:
An object linked to a #MetaKmsDevice, but where it is executed in the impl
context. It takes care of the updating of the various KMS object (CRTC,
connector, ..) states.
#MetaKmsPageFlip:
A object representing a page flip. It's created when a page flip is queued,
and contains information necessary to provide feedback to the one requesting
the page flip.