We currently track the focus of a seat in two ways: we use a list called
focus_stack to track the order in which nodes have been focused, with
the first node representing what's currently focused, and we use a
variable called has_focus to indicate whether anything has focus--i.e.
whether we should actually treat that first node as focused at any given
time.
In a number of places, we treat has_focus as implying that a focused
node exists. If it's true, we attempt to dereference the return value of
seat_get_focus(), our helper function for getting the first node in
focus_list, with no further checks. But this isn't quite correct with
the current implementation of seat_get_focus(): not only does it return
NULL when has_focus is false, it also returns NULL when focus_stack
contains no items.
In most cases, focus_stack never becomes empty and so this doesn't
matter at all. Since focus_stack stores a history of focused nodes, we
rarely remove nodes from it. The exception to this is when a node itself
goes away. In that case, we call seat_node_destroy() to remove it from
focus_stack and free it. But we don't unset has_focus if we've removed
the final node! This lets us get into a state where has_focus is true
but seat_get_focus() returns NULL, leading to a segfault when we try to
dereference it.
Fix the issue both by updating has_focus in seat_node_destroy() and by
adding an assertion in seat_get_focus() that ensures focus_stack and
has_focus are in sync, which will make it easier to track down similar
issues in the future.
Fixes#6395.
[1] There's some discussion in #1585 from when this was implemented
about whether has_focus is actually necessary; it's possible we could
remove it entirely, but for the moment this is the architecture we have.
Historically we've been sticking with the last release number in
the master branch. However that's a bit confusing, people can't
easily figure out whether they're using a release or a work-in-progress
snapshot. Only the commit hash appended to the version number may
help, but that's not very explicit and disappears when using a
tarball.
We could bump the version in master to the next release number.
However during the RC cycle there would be a downgrade from 1.8 to
1.8-rc1. Also it would be hard to tell the difference between a
stable release and an old snapshot.
This patch introduces a new pre-release identifier, "dev". It's
alphabetically before "rc" so it should be correctly sorted by
semver comparisons. "dev" is upgraded to "rc" (and then to stable)
when doing a release. The master branch always uses a "dev"
version, only release branches use "rc" or stable versions.
cairo_image_surface_create can fail, e.g. when running out of
memory or when the size is too big. Avoid crashing in this case.
Closes: https://github.com/swaywm/sway/issues/6531
Now output_begin_destroy emits the node::destroy event similar to
workspace_begin_destroy. It currently has no listeners, since they
listen to output::disable or wlr_output::destroy instead.
We use the headless backend to create a special fallback output
used when no other output is connected. However this messes up the
"real" headless output names users have come to expect (e.g.
currently the first headless output will be named "HEADLESS-2"
instead of "HEADLESS-1").
Fix this by setting the output name with [1].
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3395
Make the status command a process group leader and change the kill(2)
calls to target the new process group. Signals sent by swaybar will then
be received by both the status command and its children, if any. While
here, check the result of fork(2).
Without this, children spawned by the status command may not receive the
signals sent by swaybar. As a result, these children may be orphaned on
reload.
The issue could be shown by setting the bar to
bar {
status_command i3status | tee /tmp/i3status.out
}
which would leave orphaned processes for each reload of sway
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43633 43624 sh -c i3status | tee /tmp/i3status.out
43634 43633 i3status
43635 43633 tee /tmp/i3status.out
$ swaymsg reload
$ ps o pid,ppid,cmd | grep i3status | grep -v grep
43634 1 i3status
43635 1 tee /tmp/i3status.out
43801 43788 sh -c i3status | tee /tmp/i3status.out
43802 43801 i3status
43803 43801 tee /tmp/i3status.out
This fixes#5584.
sway-bar(5) says:
> For compatibility with i3, bar mode <mode> [<bar-id>] syntax is
> supported along with the sway only bar <bar-id> mode <mode> syntax.
while the actual behavior is that `bar_cmd_mode` ignores already
selected `config->current_bar` and applies the change to all the
configured bars.
This makes it possible to hint to the renderer and backends how many
bits per channel the buffers that the compositor draws windows onto
should have. Renderers and backends may deviate from this if they
do not support the formats with higher bit depth.
Proprietary drivers require --unsupported-gpu to be allowed, and IPCs
require no option to be passed.
The only way to satisfy both is to run IPCs before checking for
proprietary drivers.
Wayland compositors handle many file descriptors: client
connections, DMA-BUFs, sync_files, wl_data_device pipes, and so
on. Bump the limit to the max.
Closes: https://github.com/swaywm/sway/issues/6285
Add a subcommand for `smart_gaps` that enables outer gaps only
on workspaces with exactly one visible child.
Also add documentation for `smart_gaps toggle`.
previously, fullscreen global containers would grab cursor input
even if a shell-layer surface was on top of it
related issue: https://github.com/swaywm/sway/issues/6501
If the focused container is floating by itself, create a new container
in tiling mode as a sibling of the inactive focused container instead of
creating it as a sibling of everything that is in tiling mode in that
workspace. This is the i3 behavior.
seat_get_focus_inactive_floating and seat_get_focus_inactive_tiling do
not always return a view, so get the previously focused view from the
container with seat_get_focus_inactive_view. This is the i3 behavior.
If the destroyed xwayland view is in transaction, it won't
be destroyed immediately. wlr_xwayland_surface then becomes
dangling pointer.
Closes#6605Closes#5884
Nvidia has historically been a bad actor in the open-source graphics
ecosystem because they required a special EGLStreams code-path
instead of exposing the de-facto standard GBM API. However, with
their upcoming release they now support GBM as well.
This is a push in the right direction for Nvidia, so there's no
reason we should be more hostile to them than to any other proprietary
driver. Let's remove the --my-next-gpu-wont-be-nvidia flag, and advise
users to use --unsupported-gpu now.
Note, proprietary Nvidia drivers are still unsupported by the Sway
project (just like all other proprietary drivers).
