error() is not posix but gnu extension so may not be available on all
kind of systemsi e.g. musl.
Signed-off-by: Randy 'ayaka' Li <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
If the user is in group 0, we'd exit the loop early with a failure. Make sure
we run through all groups.
https://gitlab.freedesktop.org/wayland/weston/issues/86
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
[Pekka: fix one whitespace]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Explain that -u requires root and -t requires -u. Most importantly,
document in what format does -t expect the tty to be given.
It has been confusing, because Weston's --tty option takes an integer,
weston-launch takes a full device path.
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>
Fix an issue introduced in:
commit ab4999492c
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Fri Jul 19 21:26:24 2013 -0700
weston-launch: Drop sleep_fork option
where the option string accidentally became "t::". That causes
$ weston-lauch -t /dev/tty4
to be parsed incorrectly, as if -t option had no argument and the tty
path gets passed to weston which errors out because of it.
This patch fixes the above to work as expected.
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>
setup_tty() function uses the tty argument for choosing the tty/VT only
if wl->new_user (the -u option) is given. If the tty option is given
without -u, it will only be used for misleading error messages.
To make it clear to the user that -t without -u does not work the way
one might think, let weston-launch exit with an error in that case.
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>
HAVE_LIBDRM was used as a condition for the launcher infrastructure to
call libdrm.so functions. It was set by an independent test for libdrm,
which would silently continue if libdrm was not found. It was assumed
that if you enabled a feature that used libdrm at runtime, the test for
that feature would imply that HAVE_LIBDRM is also set. This was quite
subtle.
The only feature that actually uses libdrm.so at runtime is the DRM
backend. No other backend needs the libdrm calls in the launcher
infrastructure.
Therefore to simplify things, stop using HAVE_LIBDRM and use
BUILD_DRM_COMPOSITOR instead. If you enable the DRM compositor, you
automatically also get libdrm support in the launchers.
There are still things depending on LIBDRM_CFLAGS and LIBDRM_LIBS, so
the test cannot be removed completely.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This way, the environment is correctly preserved for weston. Since
commit 636156d5f6, clearenv() is only
called when we open a new PAM session, so it makes sense to only use a
login shell in that case.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This clarifies what is supposed to be the libweston code.
v2: screen-share.c is already in compositor/ instead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
Exit the program if an unrecognized command line option is found.
Signed-off-by; Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Tested-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
According to POSIX standard "upon successful completion, putenv() shall
return 0; otherwise, it shall return a non-zero value." Unlike in
setenv() we should not be checking only for negative values.
Signed-off-by: Dawid Gajownik <gajownik@gmail.com>
error(1, ...) already will exit, per man page: "If status has a nonzero
value, then error() calls exit(3) to terminate the program using the
given value as the exit status." So exit(EXIT_FAILURE) is never
reached.
The EXIT_FAILURE macro is guaranteed to be non-zero. Typically it's
just 1, but on some systems (e.g. OpenVMS apparently) exit(1) means
success so EXIT_FAILURE there is defined to some other non-zero value.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
For functions that test if something is true/valid and return a 1
or 0, it makes sense to switch to bool.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If libdrm is available, weston-launch and launcer-util.c will support
getting the drm device and setting and dropping drm master, otherwise
we'll only support getting input devices.
On shutdown, we can risk having a pending vt switch that we normally
handle in the vt signal handler. However as we put the vt back in VT_AUTO
mode, the pending VT switch will go through and if we haven't dropped
drm master at that point, we could switch to another display server
without dropping drm master. That will typically crash the other server,
so let's try to make sure we don't do that.
https://bugs.freedesktop.org/show_bug.cgi?id=70877
We used to leak the input fds, as weston would reopen all fds on vt
enter. We could just close them after sending the open fd through the
socket, but this patch also adds support for the new EVIOCREVOKE evdev
ioctl, that revokes the fd in question (including the copy that we
sent to the compositor).
https://bugs.freedesktop.org/show_bug.cgi?id=70849
weston-launch has two supported use cases now: either launch from
and VT login as a regular user (running within that session) or
from an init script (systemd or such) with the -u option to create
a session for the specified user. Running from within X or ssh is
not possible. It's still possible to run weston as root from X or ssh
but that's strictly a development/debug/test feature.
https://bugs.freedesktop.org/show_bug.cgi?id=69727
The struct weston_launcher object will now either handle tty and vt switching
details in-process (when running weston directly as root) or talk to
the weston-launch process.
The current code works if pw->pw_shell is bash because:
"If the shell is started with the effective user (group) id not equal to
the real user (group) id, and the -p option is not supplied, these actions
are taken and the effective user id is set to the real user id."
Thus, for bash, weston's EUID == UID.
For zsh, the -p option "is enabled automatically on startup if the effective
user (group) ID is not equal to the real user (group) ID."
Thus, weston's EUID = 0, and if pw_shell is zsh, /run/user/$UID/wayland-0 is
created with euid root and not writeable by the user, causing all clients to
fail.
Fix this by always dropping privileges to the user.
Regression introduced in 636156d.
Instead, forward signal to weston and wait for weston to clean up nicely.
Weston relies on weston-launch being around to shut down correctly,
so don't exit until we get the SIGCHLD from weston. This make
killall weston-launch work properly.
https://bugs.freedesktop.org/show_bug.cgi?id=62910
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
The array of arguments supplied to execv must be NULL terminated. If
unitialized values are used as pointers the exec call may fail with a
EFAULT error ("Bad address").
https://bugs.freedesktop.org/show_bug.cgi?id=64874
This patch brings back the user environment from the shell.
In the future, weston-launch could create the Wayland socket earlier, in
which case the user's shell could be used to run Wayland-specific tools
in the new Weston session.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Before this commit, weston-launch returned 0 if weston was killed by a
signal. This makes it hard to automatically test weston by using
weston-launch, as there is no way to know why weston was terminated.
This commit makes weston-launch return 10+N instead, where N is the code
of the signal that terminated weston. 10 was chosen because it allows a
script to distinguish it from the case that weston-launch itself was
killed by a signal (128+N), and does not overlap the standard exit codes
defined in sysexits.h.
Partial fix for https://bugs.freedesktop.org/show_bug.cgi?id=60935. I
can't reproduce the SIGHUP using the fbdev backend.
v3: better commit message.