Add a command line option to disable the default flight recorders
so we can save a little bit of CPU and memory on systems where
this isn't necessary.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Pass log scopes from the command line to subscribe log scopes
dynamically to the 'logger' subscriber.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
The desktop-shell-specific bindings were identified from
shell_add_bindings in desktop-shell/shell.c. Various general shortcuts
(like Ctrl+Alt+F) are provided by files in libweston/ and compositor/ .
Also introduce references to the new manual in weston(1) and weston.ini(5).
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Screenshots of the outputs can only be taken by having a keyboard
plug-ed in, as to avoid potential malicious intent. On the other hand,
this is problematic as there are cases where a keyboard cannot
be used as a input device. A particular use-case is that for
multiple devices it can be cumbersome to connect a keyboard such
that using ssh can be much easier and can be further automated.
This patch allows taking screenshots without the need of having a
keyboard connected when debug protocol is enabled.
Add also a few words about the fact that this is a serious issue
and can lead to silently leaking the output contents.
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
It's a bit surprising that Weston looks different when launched from the root
of the git repo vs from elsewhere.
But it's also technically a security vulnerability: if I launch it from
a directory like /tmp, it might pick up a weston.ini created by another user,
which could then load modules with arbitrary code. Basically, it's the same
problem as including "." in $PATH.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Let users enable the compositor debug protocol on the compositor command
line. This allows weston-debug tool to work.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Change format of substituted variables to follow the pattern used by
configure_file() in Meson.
This helps the migration to Meson, making man/meson.build much cleaner.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Catching an ABRT is kind of ok, catching a SEGV is russian roulette. We
have been quite lucky with it, but I've started hitting crashes inside
malloc() which causes a deadlock when our SEGV handler needs to malloc()
as well (weston_log_timestamp()).
One reason to catch SEGV and ABRT was to attempt to restore the VT on
the DRM-backend. Nowadays that job is done by logind or weston-launch.
The signal handler also printed a backtrace, which for me personally has
been extremely helpful. Arguably it's not necessary though, when we have
core files and services that catch cores. For instance, if using
systemd, 'coredumpctl gdb' is delightfully easy for getting into the
saved core.
Therefore, this code does more harm than it is useful, so remove it. We
also drop an optional dependency to libunwind.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Logind has been long supported as means to launch Weston without
weston-launch. It's good to note it in the manual.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
When you need to start Weston via weston-launch, systemd unit, or any
other runner, it is annoying to try to get in with a debugger,
especially if the thing you are interested in happens at start-up. To
make it easy, a new option is introduced.
The new option, implemented both as a command line option and a
weston.ini option, raises SIGSTOP early in the start-up, before the
weston_compositor has been created. This allows one to attach a debugger
at a known point in execution, and resume execution with SIGCONT.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Ian Ray <ian.ray@ge.com>
This is a follow-up for the patch that removed weston-screensaver. The
aim is to clean up shell.c a little by removing non-essential
components. Vanilla Weston desktop is only a demo, external projects are
encouraged to create user-friendly desktop environments.
The support for launching a screensaver client and the protocol bindings
are removed. With them, all related configuration options are removed,
and the manuals are updated accordingly.
The screensaver protocol definition is left in desktop-shell.xml for
posterity.
This does not affect Weston's or desktop-shells ability to put screens
to sleep after inactivity. The inactivity timer continues to operate as
before. Also screen locking is unaffected.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Add a command line option to specify a file to be read instead of
weston.ini.
IVI-shell testing will at least temporarily need to specify a config
file, because it cannot run without. That is why this is being added,
but should be convenient for everybody, too.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
We have the Weston command line option '--no-config' which is meant to
prevent loading weston.ini at all. It works for Weston itself, but it
does not work for any clients that also want to read weston.ini.
To fix that, introduce a new environment variable WESTON_CONFIG_FILE.
Weston will set it to the absolute path of the config file it loads.
Clients will load the config file pointed to by WESTON_CONFIG_FILE. If
the environment variable is set but empty, no config file will be
loaded. If the variable is unset, things fall back to the default
"weston.ini".
Note, that Weston will only set WESTON_CONFIG_FILE, it never reads it.
The ability to specify a custom config file to load will be another patch.
All programs that loaded "weston.ini" are modified to honour
WESTON_CONFIG_FILE.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tablet shell is long gone. Might as well list what we have now.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Useful for unit tests. If Weston finds a weston.ini during unit tests,
it will load it and all the modules it asks for. We need a way to
prevent loading arbitrary modules from the command line.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Config file, WAYLAND_SOCKET, XDG_CONFIG_HOME, segfault handler.
NOTE: This is a candidate for the stable branch
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add some documentation about the DRM backend into its own man page, and
refer to it in weston(1).
Environment variable, that are reserved for backends, and currently used
only by the DRM backend, are moved to weston-drm page.
NOTE: This is a candidate for the stable branch
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Instead of hardcoding drm-backend.so as the default if environment
presents neither Wayland nor X11, have a ./configure option to change
it. It still defaults to drm-backend.so, if not given.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The generic module loading must be used now to load xserver.so.
Option --xserver was removed by
a6813d2887.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
We can now load any number of general modules, and the shell and xwayland
are just two of them. We continue to use the mechanism for testing but
custom input drivers or logging mechanisms, for example are other use cases.