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.
Per the xdg-toplevel-drag protocol: "The attached window does not
participate in the selection of the drag target."
When the cursor is over the dragged toplevel, temporarily disable its
scene node and perform a second hit test to find the surface underneath.
This allows drop targets to receive pointer focus while dragging.
Also maintain pointer focus on the drag origin surface when the cursor
moves outside all windows, preventing drag motion from stopping.
Make toplevels attached to an xdg-toplevel-drag automatically float, and
position them at the cursor when first mapped.
This enables the typical tab tear-off workflow:
1. User starts dragging a tab in a browser
2. Browser creates a new toplevel attached to the drag
3. Sway floats the toplevel and positions it at the cursor
4. The motion handler (from previous commit) keeps it moving with cursor
Add support for tracking xdg-toplevel-drag operations and moving the
attached container during drag motion events.
Implementation detail:
- Track the dragged surface ourselves rather than trusting wlroots'
toplevel pointer, which may not be NULLed promptly during destruction.
This mirrors Mutter's approach with dragged_surface.
- Use find_xdg_view_with_toplevel_drag() which searches through sway's
views and uses wlroots' wlr_xdg_toplevel_drag_v1_from_wlr_xdg_toplevel()
for safe comparison, avoiding stale pointer access. There could be a
better way to do this.
- Account for XDG surface geometry offset when positioning the container.
- Add container_floating_update_scene_position() helper that updates the
scene graph position immediately, bypassing the transaction system's
batching for smoother visual feedback during drag operations.
- Clean up container tracking in seatop_unref when container is destroyed.
Add the xdg-toplevel-drag-v1 protocol manager to the server. This
protocol allows clients to attach a toplevel window to an ongoing
drag-and-drop operation, enabling features like browser tab tear-off.
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.
