xdg_shell and xwayland handled geometry changes differently despite
needing mostly identical behavior. The xwayland implementation has been
changed to match that of xdg_shell.
The size of a tiled container cannot change in response to new buffer
sizes, so there is no need to commit a new transaction. Instead, simply
recenter the view with the new geometry, leaving the full transaction
flow for floating containers.
We need to use surface_x and surface_y when rendering and damaging saved
buffers as these compensate for views that have been centered due to
being smaller than their container.
Add them to the surface positions on the saved buffer so we have the
values from the time the buffer was saved.
wlr_output_configuration_head_v1_create normally fills out the head
"enabled" field to match the wlr_output state. We overwrite this to also
set the head as enabled if it is only turned off with DPMS.
However, in some cases we may not have a mode for this display, in which
case setting it as enabled will lead to a segfault later on. Therefore,
enabled conditional on the presence of a mode.
Instead of calling wlr_xdg_surface_for_each_popup and then
wlr_surface_for_each_surface, use the new for_each_popup_surface helper
introduced in [1] that does it in one go.
[1]: https://github.com/swaywm/wlroots/pull/2609
In i3, the workspace_layout command does not affect the
workspace layout. Instead, new workspace level containers
are wrapped in the desired layout and the workspace layout
always defaults to the output orientation.
Currently, when sway sends a configure with some geometry and the
client responds with a different geometry in a commit that acks that
configure, sway ignores the new size. Sway applies the surface
geometry it had requested to the container, not what was actually
committed, in the following transaction.
This change allows any client commit to change its surface geometry,
even if it is a response to a configure event.
Sway maintains a list of pending transactions, and tries to merge
consecutive transactions applying to the same views into one. Given
a pending transactions list on views {A, B, C} of:
A -> A' -> A'' -> B -> B' -> B''
Sway will collapse the transactions into just A'' -> B''. This works
fine when doing things like resizing views by their border. However,
when interactively resizing layouts like H[V[A B] C], we end up with
pending transaction lists like:
A -> B -> C -> A' -> B' -> C' -> A'' -> B'' -> C''
Previously, Sway would not be able to simplify this transaction list,
and execute many more transactions than would be necessary (the final
state is determined by {A'', B'', C''}).
After this commit, the transaction list gets simplified to A'' -> B'' ->
C'', resolving performance problems (that were particularly noticeable
with high-refresh-rate mice).
Fixes#5736.
Xwayland views are aware of their coordinates, so validating transaction
completions should take into account the reported coordinates of the
view. Prior to this commit they didn't, and matching dimensions would
suffice to validate the transaction.
Also introduced `transaction_notify_view_ready_immediately` to support
the fix from d0f7e0f without jumping through hoops to figure out the
geometry of an `xdg_shell` view.
Sway logical coordinates are doubles, but they get truncated to integers
when sent to Xwayland through `xcb_configure_window`. X11 apps will not
respond to duplicate configure requests (from their truncated point of
view) and cause transactions to time out.
Fixes#5035.
i3 shows indicators for the workspace-level pseudo-split, but Sway does
not, as of b977c02. This commit replaces the floating container check
with a call to `container_is_floating`, which has some more robust
checks in place.
Fixes#5699.
My primary issue was IntelliJ IDEA's code suggestion pop-up not returning focus
to the active editing window.
I have spent some time looking at the changes of @Xyene (#5398) and
@RyanDwyer (#2103). I think my proposed change maintains the status
quo for the most part whilst fixing my focus issue.
I have verified that @Xyene's fix for IntelliJ sub-menus still works.
I have done basic testing which consists of:
- Chrome
- IntelliJ IDEA 2020.2.1
- VSCode
- Alacritty
It seems to hold up. I at least didn't see any obvious errors.
Relates to #3007
Instead of listening to both transform and scale events, we can listen
to the commit event and use the new wlr_output_event_commit struct to
decide what to do.
This de-duplicates some of the work we were doing twice when an output
was re-configured.
Depends on [1].
[1]: https://github.com/swaywm/wlroots/pull/2315
Usually it should be enough to simply not grant a client's
minimize request, however some applications (Steam, fullscreen
games in Wine) don't wait for the compositor and minimize anyway,
getting them stuck in an unrecoverable state.
Restoring them immediately lead to heavy flickering when unfocused
on my test application (Earth Defense Force 5 via Steam), so it's
preferable to grant their request without actually minimizing and
then restoring them once they are in focus again.
Previously, we called output_disable prior to wlr_output_commit. This
mutates Sway's output state before the output commit actually succeeds.
This results in Sway's state getting out-of-sync with wlroots'.
An alternative fix [1] was to revert the changes made by output_disable
in case of failure. This is a little complicated. Instead, this patch
makes it so Sway's internal state is never changed before a successful
wlr_output commit.
We had two output flags: enabled and configured. However enabled was set
prior to the output becoming enabled, and was used to prevent the output
event handlers (specifically, the mode handler) from calling
apply_output_config again (infinite loop).
Rename enabled to enabling and use it exclusively for this purpose.
Rename configure to enabled, because that's what it really means.
[1]: https://github.com/swaywm/sway/pull/5521
Closes: https://github.com/swaywm/sway/issues/5483
If a client commits a new size on its own, we create a transaction for
the resize like any other. However, this involves sending a configure
and waiting for the ack, and wlroots will not send configure events when
there has been no change. This leads to transactions timing out.
Instead, just mark the view ready immediately by size when the client
is already ready, so that we avoid waiting for an ack that will never
come.
Closes: https://github.com/swaywm/sway/issues/5490
The centering logic needs to take borders, titlebars and CSDs into
account. Instead of using the main surface geometry, use the container
and view geometry, which account for this.
During the execution of a resize transaction, the buffer associated
with a view's surface is saved and reused until the client acknowledges
the resulting configure event.
However, only one the main buffer of the main surface was stored and
rendered, meaning that subsurfaces disappear during resize.
Iterate over all, store and render buffers from all surfaces in the view
to ensure that correct rendering is preserved.
This is necessary because some applications (e.g. Jetbrains IDEs)
represent their multi-level menus as unmanaged surfaces, and when
closing a submenu, the main menu should get input focus.
Closes#5347.
Instead of removing the destroy listeners in the output destroy, remove
them in the damage destroy handler. Fixes the following use after free:
==646625==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200017cab8 at pc 0x0000004f8f29 bp 0x7ffdf465ad30 sp 0x7ffdf465ad20
WRITE of size 8 at 0x61200017cab8 thread T0
#0 0x4f8f28 in wl_list_remove ../common/list.c:181
#1 0x43dd24 in handle_destroy ../sway/desktop/output.c:790
(`wl_list_remove(&output->damage_destroy.link);` here, 214e3030e1dce master branch)
#2 0x7f0e573a1c93 in wlr_signal_emit_safe ../util/signal.c:29
#3 0x7f0e57390954 in wlr_output_destroy ../types/wlr_output.c:365
#4 0x7f0e5735e37f in backend_destroy ../backend/x11/backend.c:128
#5 0x7f0e57348147 in wlr_backend_destroy ../backend/backend.c:47
#6 0x7f0e57356f75 in multi_backend_destroy ../backend/multi/backend.c:54
#7 0x7f0e5735710e in handle_display_destroy ../backend/multi/backend.c:107
#8 0x7f0e573f23e4 in wl_display_destroy (/lib64/libwayland-server.so.0+0x93e4)
#9 0x42f0b2 in server_fini ../sway/server.c:177
#10 0x42dd01 in main ../sway/main.c:414
#11 0x7f0e570f7041 in __libc_start_main (/lib64/libc.so.6+0x27041)
#12 0x40e3bd in _start (/opt/wayland/bin/sway+0x40e3bd)
0x61200017cab8 is located 120 bytes inside of 320-byte region [0x61200017ca40,0x61200017cb80)
freed by thread T0 here:
#0 0x7f0e57aa9357 in __interceptor_free (/lib64/libasan.so.6+0xb0357)
#1 0x7f0e5738b877 in wlr_output_damage_destroy ../types/wlr_output_damage.c:143
#2 0x7f0e5738b2b9 in output_handle_destroy ../types/wlr_output_damage.c:13
#3 0x7f0e573a1c93 in wlr_signal_emit_safe ../util/signal.c:29
#4 0x7f0e57390954 in wlr_output_destroy ../types/wlr_output.c:365
#5 0x7f0e5735e37f in backend_destroy ../backend/x11/backend.c:128
#6 0x7f0e57348147 in wlr_backend_destroy ../backend/backend.c:47
#7 0x7f0e57356f75 in multi_backend_destroy ../backend/multi/backend.c:54
#8 0x7f0e5735710e in handle_display_destroy ../backend/multi/backend.c:107
#9 0x7f0e573f23e4 in wl_display_destroy (/lib64/libwayland-server.so.0+0x93e4)
previously allocated by thread T0 here:
#0 0x7f0e57aa9887 in __interceptor_calloc (/lib64/libasan.so.6+0xb0887)
#1 0x7f0e5738b532 in wlr_output_damage_create ../types/wlr_output_damage.c:91
#2 0x43e4a7 in handle_new_output ../sway/desktop/output.c:875
#3 0x7f0e573a1c93 in wlr_signal_emit_safe ../util/signal.c:29
#4 0x7f0e57357261 in new_output_reemit ../backend/multi/backend.c:143
#5 0x7f0e573a1c93 in wlr_signal_emit_safe ../util/signal.c:29
#6 0x7f0e5736030a in wlr_x11_output_create ../backend/x11/output.c:253
#7 0x7f0e5735e309 in backend_start ../backend/x11/backend.c:113
#8 0x7f0e573480fb in wlr_backend_start ../backend/backend.c:36
#9 0x7f0e57356e61 in multi_backend_start ../backend/multi/backend.c:31
#10 0x7f0e573480fb in wlr_backend_start ../backend/backend.c:36
#11 0x42f4ba in server_start ../sway/server.c:205
#12 0x42dbd7 in main ../sway/main.c:394
#13 0x7f0e570f7041 in __libc_start_main (/lib64/libc.so.6+0x27041)
Fixes#5158
With these changes, sway will respect positive exclusive zones of layer
surfaces anchored to one or three sides.
This matches the protocol, which states that a positive exclusive zone
should be respected, "if the surface is anchored to one edge or an
edge and both perpendicular edges". If the surfaces is "anchored to
only two perpendicular edges (a corner), anchored to only two
parallel edges or anchored to all edges a positive value will be
treated the same as zero".
