Fixes an issue where an already visible scratchpad window being moved due to
'scratchpad show' leaves the entire workspace at the top of the focus stack in
the old workspace. Moving by 'focus output' back to the old workspace would
focus the entire workspace instead of just the last active container.
This makes the behavior of floating containers more consistent with i3.
The coordinates of the container are scaled when the size of the
workspace it is on changes or when the container is moved
between workspaces on different outputs.
For scratchpad containers, add a new state that preserves the dimensions
of the last output the window appeared on. This is necessary because
after a container is hidden in the scratchpad, we expect it to be in the
same relative position on the output when it reappears. We can't just
use the container's attached workspace because that workspace's
dimensions might have been changed or the workspace as a whole could
have been destroyed.
CAIRO_HINT_STYLE_FULL attempts to maximize contrast at the expense
of fidelity, this makes most fonts that haven't been hand hinted,
which makes up the majority of fonts out there, appear much worse.
In the absence of explicitly set hint style, cairo will default to
CAIRO_HINT_STYLE_SLIGHT, which attempts to improve contrast while
retaining fidelity to the original shapes, which is what we want.
When a window in the scratchpad container requests for
xdg_activation_v1, it is ignored no matter what the value of
focus_on_window_activation is.
At least allow windows in the scratchpad to set the urgent flag. When
focus_on_window_activation is set to "focus", show the parent scratchpad
where the contained requested for xdg_activation_v1.
Check whether output->damage_ring.current is empty before calling
wlr_output_attach_render(). Saves us from having to un-do that
via wlr_output_rollback().
Atm we got issue with the touch position sent to the clients. While
holding contact, leaving the initial container will continue to send
motion event to the client but with the new local position from the new
container.
This seatop goal is to send the position of the touch event, relatively
to the initial container layout position.
This function was already declared in container.h but defined in
commands/swap.c for some unknown reason. Everything in commands/ assumes
the handler context has been set appropriately by the command preludes
but this function snuck its way into seatop_* which doesn't set anything
in the handler context.
The fact that the seatop drag actions manipulate the focus without
custody of the seat means they are definitely very broken in multiseat.
With `hide_edge_borders both` (or at least `vertical`),
`window_rect.y` will equal `border_thickness` for SOME windows,
but it will be 0 for windows adjacent to top screen edge.
Therefore setting it to `border_thickness` is not sufficient.
This commit changes it to the actual y offset of content
into the container.
xdg-activation is now too strict in only allowing tokens with a seat to
activate a surface. Clients may rely on this behavior for urgency hints.
The seat argument is still useful in case the client does provide a seat
so we can activate it on the desired seat.
Fixes: 842609da64 (view: make request_activate take a seat, 2022-11-30)
fixes#7394
Test cases:
* zwlr_output_configuration_head_v1_set_adaptive_sync 0->0, no change
* 0->1, enabled
* 1->0, disabled
* 1->1, no change
Similar tests with an incapable display resulted in `"Adaptive sync
failed, ignoring"` messages as expected.
Since [1], wlr_renderer_begin() can fail. Check its return value
and bail.
This fixes an assertion error (when begin() fails and then we try
to render something) after a GPU reset.
[1]: a541c9510a
This change allows the tablet tool button to be used for floating mod
resize. In addition, it attempts to ensure that tablet tool events are
consistent such that tablet v2 events and pointer events will never be
interleaved, and such that the tool buttons count will never fall out of
sync and cause tool button emulation to break.
Some of this logic is similar to what is done for tablet tool tip, but
not quite identical, because of the complication that we have to deal
with multiple inputs that can overlap eachother.
Fixes#7036.
This might be the wrong fix, but the crash is happening because the ->data
field on an xwayland surface is NULL. A NULL data field is normal for
unmanaged surfaces, however it seems clients can do weird things: They can
create a cursor lock on a regular xwayland surface then make it unmanaged
by calling override_redirect. In this case, the xwayland server should
destroy the cursor lock, which is does, but does so in the wrong order
making it try to dereference a NULL pointer after sway has acknowledged
its new unmanaged status.
```
(gdb) bt full
0 0x000055fd91934861 in warp_to_constraint_cursor_hint (cursor=0x55fd93486c00)
at ../sway/input/cursor.c:1243
sy = 605
lx = 6.9527431433545762e-310
sx = 1272
view = 0x0
con = 0x7ffd1cdfe400
ly = -6.949595189996421e+59
constraint = 0x55fd93e7faa0
1 0x000055fd91934976 in handle_constraint_destroy (listener=0x55fd93f0fd58, data=0x55fd93e7faa0)
at ../sway/input/cursor.c:1266
sway_constraint = 0x55fd93f0fd30
constraint = 0x55fd93e7faa0
cursor = 0x55fd93486c00
2 0x00007fda8275bf6e in wl_signal_emit_mutable () at /usr/lib/libwayland-server.so.0
3 0x00007fda82e57016 in pointer_constraint_destroy (constraint=0x55fd93e7faa0)
at ../subprojects/wlroots/types/wlr_pointer_constraints_v1.c:49
4 0x00007fda82e570dc in pointer_constraint_destroy_resource (resource=0x55fd933cf8f0)
at ../subprojects/wlroots/types/wlr_pointer_constraints_v1.c:66
constraint = 0x55fd93e7faa0
5 0x00007fda8275d8ba in () at /usr/lib/libwayland-server.so.0
6 0x00007fda8275f6a9 in wl_resource_destroy () at /usr/lib/libwayland-server.so.0
7 0x00007fda82e56fb3 in resource_destroy (client=0x55fd93ea52e0, resource=0x55fd933cf8f0)
at ../subprojects/wlroots/types/wlr_pointer_constraints_v1.c:39
8 0x00007fda81d8f4f6 in () at /usr/lib/libffi.so.8
9 0x00007fda81d8bf5e in () at /usr/lib/libffi.so.8
10 0x00007fda81d8eb73 in ffi_call () at /usr/lib/libffi.so.8
11 0x00007fda8275aada in () at /usr/lib/libwayland-server.so.0
12 0x00007fda8275f01c in () at /usr/lib/libwayland-server.so.0
13 0x00007fda8275d9e2 in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
14 0x00007fda8275e197 in wl_display_run () at /usr/lib/libwayland-server.so.0
15 0x000055fd919264d3 in server_run (server=0x55fd919a3a80 <server>) at ../sway/server.c:320
16 0x000055fd91925457 in main (argc=1, argv=0x7ffd1cdfed98) at ../sway/main.c:411
verbose = false
debug = false
validate = false
allow_unsupported_gpu = false
config_path = 0x0
c = -1
```
sway sends wl_keyboard.enter on seat focus change and when a keyboard
active on a seat is configured. If all keyboards are removed and a
keyboard is added back without changing the focused client, no new
notify event would be sent despite having keyboard focus. This could
lead to key events without notify, which is a protocol violation.
As a quick fix, when configuring a keyboard on a seat where no keyboard
is currently active, activate the keyboard so that a focused surface
will receive a notify event.
Regressed by: e1b268af98
Closes: https://github.com/swaywm/sway/issues/7330
efd83cb8 added the rotation_angle command but it didn't insert it in
the proper place in the list, so the repeat_delay and repeat_rate
commands became unusable.
See: https://github.com/swaywm/sway/issues/4511
Adds a bool config option `primary_selection`, which explicitly
enables/disables the primary selection clipboard. Defaults to enabled.
This is implemented as a launch-only option which enables or disables the creation of the
`zwp_primary_selection_device_manager_v1` global.
Co-authored-by: Tilde Rose <t1lde@protonmail.com>
When we reload the config, we reset every input device and re-apply
configuration from the config file. This means that the keyboard keymap
is updated at least once during config reload, more if the config file
contains keyboard configuration.
When they keyboard keymap changes and is updated through wlr_seat, the
keymap ends up sent to every keyboard bound in every client, seemingly
multiple times. On an x230 of mine with a keyboard layout set in the
config file, I see 42 keymap events sent to foot on config reload.
Reduce events from keyboard configurations by skipping all but the
currently active keyboard for the seat, and by clearing the active
keyboard during input manager device reset. After this change, I only
see a single just-in-time keymap event.
Fixes: https://github.com/swaywm/sway/issues/6654
Views now maintain a reference to a launch context which, as a last
resort, is populated at map time with a context associated with its pid.
This opens the possibility of populating it before map via another
source, e.g. xdga-tokens or configuration.
This removes the need to rename the pid_workspaces when a workspace
is renamed.
It also opens the possibility of tracking other node types. Tracking
containers would allow application to be placed correctly in the
container tree even if the user has moved their focus elsewhere since
it was launched.
Any windows that have never had a title set visually behave closer to
that of an empty title, but are unformattable, as the code bails out
early on a NULL title.
Support the new dwtp (disable while trackpointing) option introduced in
libinput 1.21, allowing users to control whether the trackpoint (like
those in Thinkpads, but not only) should be disabled while using the
keyboard/touchpad.
See: https://gitlab.freedesktop.org/libinput/libinput/-/issues/731
Remove the incorrect attempt to block focus changes when an input grab
is present and replace it with the same logic used for layer_shell-based
screen lockers: restore the focus after changing it.
This fixes a use-after-free of seat->workspace if outputs are destroyed
while a screen lock is enabled.
When removing outputs, it is possible to end up in a situation where
none of the session lock client's surfaces have keyboard focus,
resulting in it not receiving keyboard events. Track the focused
surface and update it as needed on surface destroy.
Sway focuses the inactive child when focusing split containers. However,
there is currently no way to focus the parent container itself by mouse.
A user must use the keyboard to do so.
This commit maintains the current behavior, but makes it such that a
second click on the split container titlebar (i.e., after its children
are visible) focuses the split container itself.