This can cause issues such as the window not being shown at the exact
same coordinates when the old and new wlr_box aren't the same
dimensions and the container is being moved back-and-forth between them.
For example, in the case where a floating window gets moved
from one output to another but the outputs aren't the same resolution.
For e.g. have two displays that aren't the same resolution then:
1. Open a floating window and set it to pos 0,0 on output 2
2. Send it to scratchpad then `scratchpad show` on output 1
3. `scratchpad show` on output 2 again
Observe that the window isn't at 0,0 on output 2 anymore.
When moving a container to a new workspace, the workspace's dimension
are left unset. Usually this doesn't matter, but when moving a floating
container to a new workspace on a different output, this leads to the
position of the container being calculated with 0, so the container ends
up halfway offscreen on the leftmost topmost monitor.
Signed-off-by: Anna (navi) Figueiredo Gomes <navi@vlhl.dev>
When doing an output configuration search, the intent is to only look
for modes if the output's configuration does not contain a specific
mode. This was done by testing if config_has_auto_mode returned false.
config_has_auto_mode had its return values backwards, leading to other
modes being tested if the output configuration had specified modes or
modelines, leading to unwanted modes being selected.
Invert the function to config_has_manual_mode to give it a clearer name,
and fix the return values in the process.
After 4e38f93f36 ("config/output: Skip VRR tests when not supported"),
the configuration search no longer touches VRR state for outputs that
are known to not support it. This also means that it will not remove VRR
if already set, which could cause output configuration to fail.
Ensure that VRR state is never set for outputs that do not support it by
adding the same test for support to queue_output_config.
Fixes: 4e38f93f36 ("config/output: Skip VRR tests when not supported")
Fixes: https://github.com/swaywm/sway/issues/8296
Note that in the `sway_keyboard_configure` function of sway/input/keyboard.c,
we have skipped the `sway_keyboard_set_layout` function for virtual
keyboards, which then have null keymaps.
Hence, a null-safety check is needed at runtime.
daaec72ac0 ("desktop/xwayland: restack surface upon activation")
has updated Sway for wlroots commit bfc69decdd04 ("xwm: do not
restack surfaces on activation"). However, it unconditionally
restacks the window above all other windows even if marking the
window as inactive.
Closes: https://github.com/swaywm/sway/issues/7974
Commit 188811f808 ("scene_graph: Port layer_shell") accidentally
removed code in `arrange_layers` to handle focus on layer shell
surfaces with keyboard interactivity.
Due to this, layer shell surfaces requesting exclusive keyboard
interactivity may not get automatically focused, and layer shell
surfaces giving up exclusive keyboard interactivity can remain focused.
Add the previous code back to fix the problem.
Note the non-rename change included in b4d7e84d38 ("desktop: Rename
layers to shell_layers") is not included as it also seems accidental.
Fixes: #7936
1e0031781f refactored repaint to accumulate all changes in a single
wlr_output_state and commit them at the end of the repaint loop,
replacing a call to wlr_scene_output_commit. wlr_scene_output_commit
contains an early bail-out when no frame has been requested and no
damage has accumulated, which was not replicated as part of this
refactor, causing the repaint loop to never pause.
Replicate the logic to stop the repaint loop as needed.
Fixes: 1e0031781f ("desktop/output: unify page-flip codepath")
If the launched client decides to pass it's token along as an activation
request, allow that. This will make the behavior match tokens provided by
an external launcher client.
When a floating container has a titlebar, render_backing_buffer()
ends up being called each time the container is moved. Add some
more checks for no-op changes in sway_text_node_set_max_width()
and sway_text_node_set_background(). This makes the move smoother.
the surface isn't initialized yet when we first handle it in
`handle_xdg_shell_toplevel`, move setting WM capabilities to
handle_commit instead.
Fixes warnings from wlroots about a configure being scheduled for
uninitialized surface
"The compositor must not send this event if the wl_keyboard did not
have an active surface immediately before this event. The compositor
must not send this event if state is pressed (resp. released) and the
key was already logically down (resp. was not logically down)
immediately before this event."
From https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/382
Adaptive sync is a "soft" setting which we degrade of off when not
supported. Some outputs types do not support turning it off (Wayland,
X11), which makes for an awkward three-way test where we first enable,
disable and finally unset the setting.
wlr_output.adaptive_sync_supported tells us whether the output
definitely does not support making changes (backend without support,
connector without the feature), or whether it might work.
Use this to avoid wasting time on adaptive sync test that can never
succeed, and to avoid the Wayland/X11-backend specific unset step.
Instead of having a special codepath for applying gamma LUTs, have
a single codepath for regular page-flips and gamma LUT updates.
Should make it easier to add more logic on top e.g. for tearing
page-flips.
We were only passing the color transform when calling
wlr_scene_output_commit(). However when modesetting or pushing a
new gamma LUT we render via wlr_scene_output_build_state(). Pass
the color transform there as well.
The only reason it's included there is for a declaration of
struct sway_server, but we can just forward-declare it.
This avoids rebuilding almost all of Sway when touching server.h.
All other server.h includes are from source files, not headers.
Regular Wayland clients shouldn't care about the position or size
of outputs. Hide xdg_output from unprivileged clients to make sure
they're not doing shenanigans with this information.
If a floating window is using CSD, the geometry should not be used to
define the clipping region. Otherwise drop shadows and such may be
clipped excessively.
Instead of having a build-time option to enable/disable xwayland
support, just use the wlroots build config: enable xwayland in
Sway if it was enabled when building wlroots. I don't see any
use-case for disabling xwayland in Sway when enabled in wlroots:
Sway doesn't pull in any additional dependency (just pulls in
dependencies that wlroots already needs). We have a config command
to disable xwayland at runtime anyways.
This makes it so xwayland behaves the same way as other features
such as libinput backend and session support. This also reduces
the build matrix (less combinations of build options).
I think we originally introduced the xwayland option when we didn't
have a good way to figure out the wlroots build config from the
Sway build system.
If there's no config for the output, oc is null, but some screens might
have a default rotation, causing the log call to dereference a null
pointer.
Signed-off-by: Anna (navi) Figueiredo Gomes <navi@vlhl.dev>
