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.
Update the information about display manager support (see #8861), as
well as markdown formatting of links and change some wording in the
German README.
Updated italian readme to follow the recent changes to the English one.
I also removed "gestore di accesso" which in theory translates to
display manager, but in practice is never used in this context. Other
wikis such as [Debian](https://wiki.debian.org/it/DisplayManager) and
[Ubuntu](https://wiki.ubuntu-it.org/AmbienteGrafico/DisplayManager) just
use the term "Display Manager" as is. Another small thing that I
corrected is "canale di IRC" which sounds a bit weird.
It's been a long while since we've heard about issues related to
display managers. Some used to be unreliable in the past, but by
now most issues have been ironed out. Let's start supporting them
officially.
I've considered translating other languages but I'm concerned about
messing up the sentence. I've updated languages I'm comfortable
with.
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
