When evaluating a __focused__ pattern, sway's logic is to consider the
pattern match to have failed for a given view and attribute if a view is
focused and the value of attribute in question of the focused view is
not that of the view in question. Expected behaviour is that the pattern
matches if there is a focused view and that the values of the attribute
for the focused view and the other view are equal. (See #6753, which is
the case where the `workspace` attribute is matched against.). I.e., if
we write out the function `criteria_matches_view` as a logical formula,
expected behaviour is
criteria_matches_view(criteria, view) <=>
forall (attribute, pattern) in criteria,
(pattern is __focused__ and
focused view exists and view.attribute == focused.attribute)
or
(pattern is not __focused__ and view.attribute =~ pattern)
but it is actually (pay attention to the fourth line)
criteria_matches_view(criteria, view) <=>
forall (attribute, pattern) in criteria,
(pattern is __focused__ and
(no focused view or view.attribute == focused.attribute))
or
(pattern is not __focused__ and view.attribute =~ pattern).
Fix program logic to reflect (the disjunctive form of) the first formula
to be compatible with i3. (In passing, this fixes #6753.)
This commit shows a swaynag message when an unsupported GPU is detected
which must be acknowledged by users. It also adds an environment
variable (`SWAY_UNSUPPORTED_GPU`) which may be used instead of the
`--unsupported-gpu` argument.
The `static` storage class for flag variables in main has also been
removed, as this should have no effect on the program.
Resolves: #8999
Fix documentation of sway-ipc. The example reply for GET_BINDIG_STATE is an example and not the exact reply.
This bug seems to come from copy/paste from the ipc command SYNC directly above.
handle_tool_tip() previously used event->tool->data without checking
for NULL. When launching sway for the first time after a reboot, and
then tapping with a USI 2.0 stylus, the tool tip event is fired before
the tool proximity event. As event->tool is initialized during the tool
proximity handler handle_tool_proximity(), this was causing a crash.
The fix adds a NULL check before accessing the fields of
event->tool->data. In case of a NULL, a log message is emitted
indicating that the tool tip event fired before proximity. This logic is
identical to the logic in handle_tool_axis().
Fixes issue #8907
Currently, config apply sets the output's image description before the
initial commit, but sets the output's color transform after the commit.
In the case of a config reload removing a color profile and enabling
HDR, both the color transform and image description will be set, which
trips an assert in wlroots
Closing a tiled window (mod+shift+q) while resizing (mod+click) causes
an use-after-free in handle_unref.
Both conditions can be true in this case, which will result in
dereferencing `e` on the second check after it has already been freed by
the first `seatop_begin_default`.
Fix by combining separate checks for the main container and its
horizontal/vertical siblings into a single condition.
The second check was added in 9e272a7986
and I've checked that this fix does not regress that issue.
Previously it was reporting window_menu and maximize instead of fullscreen because wlr_xdg_toplevel_set_wm_capabilities expects a bitmask (WLR_XDG_TOPLEVEL_WM_CAPABILITIES_*), and XDG_TOPLEVEL_WM_CAPABILITIES_* are supposed to be used as values in wl_array, so the values are different:
XDG_TOPLEVEL_WM_CAPABILITIES_FULLSCREEN = 3
WLR_XDG_TOPLEVEL_WM_CAPABILITIES_FULLSCREEN = 4
We currently emit errors about HDR support even if HDR is not being
requested, which mean errors on every regular modeset when monitors not
supporting HDR are connected.
Only emit errors when attempting to enable HDR on such device.
Fixes a compatibility issue with i3 where resizing works as described
hereafter:
> Direction can either be one of up, down, left or right. Or you can be
> less specific and use width or height, in which case i3 will take/give
> space from all the other containers.
Sway previously considered only the direct neighbours, not all siblings.
Fixes#5936
Applying layout changes to the parent of the parent, in case the parent only has a single child, stops the creation of a chain of single child containers.
Closes: https://github.com/swaywm/sway/issues/7945
Node destruction currently runs through the transaction system such that
a particular node is only destroyed after its use in an ongoing
transaction. If a node is dirtied after the node is marked as destroying
but before it is destroyed, the pointer added to dirty_nodes would
become a dangling pointer once the node was destroyed.
Do not dirty destroying nodes, and ensure that destroying is only set
after the last dirty.
I misunderstood the recommendation in the libinput release notes.
Instead of making enabled_sticky the default, leave the default
set to disabled.
Fixes: bbadf9b8b1 ("Add support for LIBINPUT_CONFIG_DRAG_LOCK_ENABLED_STICKY")
Closes: https://github.com/swaywm/sway/issues/8758
In general wl_signal isn't well-suited for Sway: Sway doesn't need
any modularity, and signals make it trickier to track down exactly
what happens down the stack.
Replace Sway's output disable signal with a simple list tracking
for the only user.
This reverts commit e28e6484e8.
This change tried to remove nodes from all points of reference to allow
immediate destruction. However, it missed things like the children lists
cloned by transaction states of parent nodes.
Adding all that extra cleanup would not be in the spirit of a PR
claiming to simplify teardown. Let's wait for someone to come up with a
cleaner approach instead.
Fixes: https://github.com/swaywm/sway/pull/8738
When a container is detached, we need to remove it from any lists it may
be part of. We use container_get_siblings to obtain the relevant list,
find our entry and remove it.
If the container is in a later list than the one returned by
container_get_siblings, or is in multiple lists for some reason,
container_detach will fail to remove the container, leaving a dangling
pointer when the container is freed.
Instead of calling container_get_siblings, check and remove the
container from all lists.
A sway_node may end up being referenced in either a queued transaction,
pending transaction or as a dirty node. To manage this, the transaction
system has been responsible for destroying containers, workspaces and
outputs at the end of their last referenced transaction.
This significantly complicates the teardown flow of surfaces and
outputs. Instead, remove the node from transactions and dirty lists so
that the callsite can remove and free the node immediately.
