active_keyboard may be NULL, in which case an invalid pointer could be
passed to wlr_input_method_keyboard_grab_v2_send_modifiers. This
procedure call is unnecessary since wlroots commit 372a52ec "input
method: send modifiers in set_keyboard", so the call can simply be
removed.
Fixes#6836.
Currently, a floating window that's been fullscreened can send us
xdg_toplevel::move, and we'll enter seatop_move_floating, which lets us
drag the surface around while it's fullscreen. We don't want
this--fullscreen surfaces should always be aligned to the screen--so add
the same check that seatop_default already does when entering this mode.
Tested with Weston's weston-fullscreen demo, which sends a move request
if you click anywhere on its surface.
When REAPER submenu is closed `XCB_CLIENT_MESSAGE` with type
`NET_ACTIVE_WINDOW` is sent to set focus to parent menu.
Closes: https://github.com/swaywm/sway/issues/6324
Commit 37d7bc6998 ("transaction: Only wait for ack from visible
views") introduced a check which uses view_is_visible() to check if a view
is still visible on the screen. However view_is_visible() will early
return in case the node is in the destroying state. This is incorrect
for transactions, since a destroying view which is visible will trigger
configure events for other clients. This bug was visible when repeatedly
opening and closing two views side by side, since we ignore the
destroying node we get a frame where the still open view is shown with
the old configure values and the rest is the desktop background. The
next frame is than correct again.
Fix this by considering destroying views as visible, we correctly wait
for them and send the configure events to other views in time, fixing
the background flicker.
Fixes#6473
`popup_unconstrain` uses view coordinates to init the output box for
popups. However wlroots expects the box to be set in a toplevel surface
coordinate system, which is not always equal to view. The difference
between those is a window geometry set via xdg-shell.
GTK4 reserves some space for client-side decoration and thus has a
window with top left corner not matching to (0, 0) of a surface. The box
calculated without taking that into account was slightly shifted
compared to the actual output and allowed to position part of the popup
off screen.
SUID privilege drop is needed for the "builtin"-backend of libseat,
which copied our old "direct" backend behavior for the sake of
compatibility and ease of transition.
libseat now has a better alternative in the form of seatd-launch. It
uses the normal seatd daemon and libseat backend and takes care of SUID
for us.
Add a soft deprecation warning to highlight our future intent of
removing this code. The deprecation cycle is needed to avoid surprises
when sway no longer drops privileges.
Followup on 4e4898e90f.
If a view quickly maps and unmaps repeatedly, there will be multiple
destroyed containers with same view in a single transaction. Each of
these containers will then try to destroy this view, resulting in use
after free.
The container should only destroy the view if the view still belongs
to the container.
Simple reproducer: couple XMapWindow + XUnmapWindow in a loop followed
by XDestroyWindow.
See #6605
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.
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
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