Documentation file for explaning in more detail how to run weston, using
launcher direct and specifying a non-default seat. This explains how to
create a udev file and assign a particular GPU card to it, and
potentially, other input devices. It also describes a bit additional
arguments that can be passed on, as an introduction to using the DRM
node for that particular seat.
Fixes#460
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
kiosk-shell is fullscreen shell for apps that use the xdg-shell
protocol. The goal is to make life easier for people shipping embedded
devices with simple fullscreen shell requirements, and reduce the
proliferation of desktop-shell hacks.
Top level surfaces are made fullscreen, whereas dialogs are placed on
top in the center of the output and retain their natural sizes. Dialogs
can be moved and (un)maximized, but resizing is currently not supported.
An app can be directed to a particular output by populating the
"app-ids" field with the app's XDG app id, in the relevant
"[output]" section in the weston config file.
Fixes: #277
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
With this patch we add support to run DRM-backend tests locally
in the test suite. For now this won't work in the CI, as there
are no cards available. But the plan is to achieve this by using
VKMS (virtual KMS) in the future.
To run DRM-backend tests locally, first of all the user has to
set the environment variable WESTON_TEST_SUITE_DRM_DEVICE to
'card0', 'card1' or any other device where he wants to run
the tests. Also, for now it only works if it is run as root,
but in the future this problem will be solved.
The tests will run on a non-default seat. The reason for that
is that we want to avoid opening input devices unnecessarily.
Also, since DRM-backend usage requires gaining DRM master status
on a DRM KMS device, nothing else must be using the device at
the same time. To achieve this we use a lock to run the
DRM-backend tests sequentially.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The only reason why we have both weston_compositor_tear_down() and
weston_compositor_destroy() is that the only we had to destroy
the log context was keeping weston_compositor alive and calling
weston_log_ctx_compositor_destroy().
After commit "weston-log: replace weston_log_ctx_compositor_destroy()
by weston_log_ctx_destroy()", it's not necessary to keep a zombie
weston_compositor just to be able to call
weston_log_ctx_compositor_destroy().
Fold weston_compositor_tear_down() into weston_compositor_destroy(),
as this split is useless now.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
The function weston_log_ctx_compositor_destroy(), which destroys struct
weston_log_context, takes weston_compositor as argument. We may have a
weston_log_context unlinked from a weston_compositor and currently there
is no way to destroy it.
Add function weston_log_ctx_destroy(), what makes the destruction of
weston_log_context independent of weston_compositor.
With this change, one could destroy a weston_compositor and keep the
related weston_log_context (since now weston_log_context can be destroyed
without the need of a weston_compositor). But if weston_compositor gets
destroyed it's also necessary to destroy weston_log_context::global,
as the debug protocol depends on the compositor. So a listener has been
added to the destroy signal of weston_compositor.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Since weston_log_ctx_compositor_create() does not have any relation
with weston_compositor, rename it to weston_log_ctx_create().
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
If we use the function weston_log_context_add_log_scope()
in non-core code, it's necessary to access
weston_compositor::weston_log_ctx.
This is not ideal, since the goal is to make core structs
(weston_compositor, weston_surface, weston_output, etc)
opaque.
Add function weston_compositor_add_log_scope(), so non-core
users are able to pass weston_compositor as argument instead
of weston_compositor::weston_log_ctx.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_log_scope_destroy()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_scope_destroy(), as the argument is a
struct weston_log_scope.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There's a function named weston_compositor_add_log_scope()
but it doesn't take a struct weston_compositor argument.
Rename it to weston_log_ctx_add_log_scope(), as
the log_scope is being added to a log_context.
Also, bump libweston_major to 9.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
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>
Use doxygen ingroup command as to show the symbols in the sphinx
documentation.
Include some basic comments and document the exported functions from
timeline.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This details the logging/debugging framework with the latest changes,
making use of the groups added by "weston-log: Start adding
documentation" and "libweston/log: Add 'wlog' group".
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Destroying the compositor after destroying the log scope will not print
out the messages in the tear down/clean-up phase of the compositor, so
add a new tear_down function which allows keeping a valid reference to
the compositor. This way we can destroy the compositor before destroying
the scope and keep the debug messages.
While at it remove the log context destroy part from the clean-up
of the compositor and make it stand on its own.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Demonstrates how to call/use the 'doxygen*' breathe directives. Make
use of previous patches that tag symbols using 'ingroup' doxygen
command.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This is adds basic configuration files for doxygen and for breathe,
which is a doxygen-to-sphinx bridge that can document C symbols.
Breathe is configured with default project 'weston' and implicitly adds
:members: and :undoc-members: to breathe configuration options.
This allows a shorter way to call breathe directives without the need
specify the project and also to display implicitly all the members,
documented or not.
A 'docs' run_target to force the docs to be re-built has been added.
Initially (the first time the build system is ran) the documentation
will automatically be built, but later re-builds will require the use of
the 'docs' target. This avoid further delays in building weston but in
the same time allows the possiblity to update/improve the documentation
bits to those who want that.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
