summaryrefslogtreecommitdiff
path: root/src/libsystemd-terminal/grdev.h
Commit message (Collapse)AuthorAge
* terminal: allow user-context to be retrieved/storedDavid Herrmann2014-09-22
| | | | | | | | Add "userdata" storage to a bunch of external objects, namely displays and sessions. Furthermore, add some property retrieval helpers. This is required if we want external API users to not duplicate our own object hashtables, but retrieve context from the objects themselves.
* terminal: add grdev DRM backendDavid Herrmann2014-09-19
| | | | | | | | | | | | | | | | The grdev-drm backend manages DRM cards for grdev. Any DRM card with DUMB_BUFFER support can be used. So far, our policy is to configure all available connectors, but keep pipes inactive as long as users don't enable the displays on top. We hard-code double-buffering so far, but can easily support single-buffering or n-buffering. We also require XRGB8888 as format as this is required to be supported by all DRM drivers and it is what VTs use. This allows us to switch from VTs to grdev via page-flips instead of deep modesets. There is still a lot room for improvements in this backend, but it works smoothly so far so more enhanced features can be added later.
* terminal: add graphics interfaceDavid Herrmann2014-09-19
The grdev layer provides graphics-device access via the libsystemd-terminal library. It will be used by all terminal helpers to actually access display hardware. Like idev, the grdev layer is built around session objects. On each session object you add/remove graphics devices as they appear and vanish. Any device type can be supported via specific card-backends. The exported grdev API hides any device details. Graphics devices are represented by "cards". Those are hidden in the session and any pipe-configuration is automatically applied. Out of those, we configure displays which are then exported to the API user. Displays are meant as lowest hardware entity available outside of grdev. The underlying pipe configuration is fully hidden and not accessible from the outside. The grdev tiling layer allows almost arbitrary setups out of multiple pipes, but so far we only use a small subset of this. More will follow. A grdev-display is meant to represent real connected displays/monitors. The upper level screen arrangements are user policy and not controlled by grdev. Applications are free to apply any policy they want. Real card-backends will follow in later patches.