This is unnecessary because Xwayland logic doesn't bring in new
dependencies. We can just compile in our Xwayland-related code
when wlroots has been built with Xwayland support.
See this Sway patch: https://github.com/swaywm/sway/pull/8165
wlr_scene_output_layout_add_output() aborts when called with an
already-added output.
To reproduce, run wlr-randr to reconfigure one of the enabled
outputs.
When destroying an xwayland surface, the dissociate and destroy handlers
are called, but both of these were removing the map and unmap signal
handlers, causing a segfault when the destroy handler went to remove
them.
Fixes#309
wlroots as a subproject now yields the xwayland meson option to its
parent. We need to match the type for this to work. This also adds
support for auto mode, where xwayland is used if present but no warning
is given otherwise.
The output is disabled then re-enabled using the wlr-output-management
protocol with tool such as wlr-randr.
$ wlr-randr --output HDMI-A-1 --off
$ wlr-randr --output HDMI-A-1 --on
When re-enabled the new output configuration is committed before the
output to be added to the global output layout. However,
handle_output_commit() expects the output to be already part of this
global layout and assert failed. Now, do not treat this in
handle_output_commit() and simply ensure the resulting scene output is
not NULL in handle_output_frame().
Otherwise, testing to set preferred / "best" mode will always return an
error. Consequently, output will simply be configured with last and
probably "worst" mode.
Only terminate if the last output was nested under the Wayland or X11
backend. If not, using DRM backend for example, terminating Cage when
unplugging the last monitor or simply turning it off does not seem to be
the right behavior.
wl_touch::frame() is expected to be sent to client to indicate end of
touch frame event and not sending it may cause issues.
For example, Qt applications using Qt Wayland platform plugin do not
consider touch events until this end of frame to be received.
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>
