If no application is specified, run without starting a child
process. Leave it up to the user to start applications externally
and stop cage with a signal.
For bug reports, it's useful to ask for a debug log. However there's
no way for users to enable debug logs without recompiling. Add a
CLI flag to do so.
Some applications indicate different shutdown conditions by returning
specific exit codes. One of these is e.g. Kodi, which returns 64 in case
the user chose "Power off" and 66 in case the user chose "Reboot".
In order to act on these exit codes, it thus makes sense in some
situations to pass them on from the primary client to the caller of
Cage.
This exit code is only returned if the primary client is the cause of
Cage terminating.
Co-authored-by: Patrick Steinhardt <ps@pks.im>
- Update wlr_box includes to util/box.h: the wlroots header has
been moved upstream.
- Subsurface fields have been moved
- Create renderer and allocator, stop using wlr_backend_get_renderer
- Initalize output rendering
cage.c:307:61: error: too many arguments to function call, expected single argument 'display', have 2 arguments
server.backend = wlr_backend_autocreate(server.wl_display, NULL);
~~~~~~~~~~~~~~~~~~~~~~ ^~~~
/usr/include/sys/_null.h:34:14: note: expanded from macro 'NULL'
#define NULL ((void *)0)
^~~~~~~~~~~
/usr/local/include/wlr/backend.h:36:21: note: 'wlr_backend_autocreate' declared here
struct wlr_backend *wlr_backend_autocreate(struct wl_display *display);
^
Based on 53f5197c26
This enum provides two means of behaviour for multi-output setups:
extend the display across all outputs, or only use the last one. The
former is the current (and default) behaviour; the latter will be added
in the next commit.
If something goes wrong during startup (i.e., the wlroots backend cannot
be created), we jump to the end. This then unconditionally removes the
sigchld_source, but that hasn't been set at this point yet.
With the new CLOEXEC setting, spawning the primary client
can fail *after* forking. In this case, the client process
has been forked and will need to be cleaned up.
In case something fails before pid has been set, it's set to 0.
From waitpid(2):
The value of pid can be:
0 meaning wait for any child process whose process group ID
is equal to that of the calling process at the time of the
call to waitpid().
That will be none in this case, and hence this won't block and is thus
safe.
As mentioned by @emersion:
By default, pipe creates FDs without the CLOEXEC flag set, which means
they will be leaked to any other child process spawned. Would be nice to
set the CLOEXEC flag to prevent the leak.
wl_display will destroy the outputs, whose destroy handler will remove
them from the output layout. But by that point, the output layout has
already been destroyed.
