9dccfd1ef3
When we were designing the libweston output API, I wrote a design document as a Phabricator wiki page. Phabricator is no longer accessible so that information needs to be migrated to a new place. Here I am converting most of it into libweston Sphinx documentation, particularly pulling in the sequence diagrams I drew. This should help people understand how libweston output configuration works. The diagrams are committed as both MSC source files and rendered PNG files. I did not bother tinkering with the build to run mscgen automatically and then with the CI images to install the tool. The Sphinx configuration need numref explicitly enabled so that figures are automatically numbered and can be referenced by their number rather than their whole caption text(!). The document structure is changed a little better flowing with Output Management being the overview page and the Heads and Outputs being the API pages. First I wrote the struct weston_output and weston_head descriptions in Doxygen comments in libweston.h, but then in the API page that text would have been buried somewhere towards the end of the page. So I put that text in ReST instead where it comes as first on the pages as it should. The doc for the structs only contain a link to the top of the page. Yes, the comment style in libweston.h is a little broken. If I left the asterisk there it would show up as a bullet point in Sphinx. OTOH putting everything from \rst in a single line did not produce anything. Because Sphinx cannot look in two places, the images need to be copied into the build dir too. mscgen: http://www.mcternan.me.uk/mscgen/ Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/25 Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
45 lines
1.8 KiB
ReStructuredText
45 lines
1.8 KiB
ReStructuredText
.. _libweston-head:
|
|
|
|
Heads
|
|
=====
|
|
|
|
A head is represented by a :type:`weston_head` object.
|
|
|
|
A head refers to a monitor when driving hardware, but it can also be a window
|
|
in another window system, or a virtual concept. Essentially a head is a place
|
|
where you could present an image. The image will be produced by a weston_output
|
|
where the head is attached to.
|
|
|
|
In display hardware, a head represents a display connector in a computer
|
|
system, not the actual monitor connected to the connector. A head carries
|
|
monitor information, if present, like make and model, EDID and possible video
|
|
modes. Other properties are DPMS mode and backlight control.
|
|
|
|
In terms of Wayland protocol, a head corresponds to a wl_output. If one
|
|
:type:`weston_output` has several heads, meaning that the heads are cloned,
|
|
each head is represented as a separate wl_output global in wl_registry. Only
|
|
the heads of an enabled output are exposed as wl_outputs.
|
|
|
|
Heads can appear and disappear dynamically, mainly because of DisplayPort
|
|
Multi-Stream Transport where connecting a new monitor may expose new
|
|
connectors. Window and virtual outputs are often dynamic as well.
|
|
|
|
Heads are always owned by libweston which dictates their lifetimes. Some
|
|
backends may offer specific API to create and destroy heads, but hardware
|
|
backends like DRM-backend create and destroy heads on their own.
|
|
|
|
.. note::
|
|
|
|
:func:`weston_head_init` and :func:`weston_head_release` belong to the
|
|
private/internal backend API and should be moved accordingly once that
|
|
section has been created. There are many other functions as well that are
|
|
intended only for backends.
|
|
|
|
A :type:`weston_head` must be attached/detached from a :type:`weston_output`.
|
|
To that purpose you can use :func:`weston_output_attach_head`, respectively
|
|
:func:`weston_head_detach`.
|
|
|
|
|
|
.. doxygengroup:: head
|
|
:content-only:
|