This emits frame events for the seat_cmd_cursor subcommands. The
wl_pointer frame event are required to notify clients when to process
the events. It will now be emitted after cursor movement, button press,
button release, and axis events.
This is a tiny cleanup commit that renames `simulated_tool_tip_down` to
`simulating_pointer_from_tool_tip`, making it match
`simulating_pointer_from_touch`.
This is a better name since it makes it clear that it's the *pointer*
that's being simulated, not the tool tip.
After swaywm/wlroots#2023, #4996 inverted configuration transformations.
For consistency, we should undo (double-apply) the inversion when
communicating via IPC.
Closes#5356.
The spec has this to say about sending events on confine creation:
Whenever the confinement is activated, it is guaranteed that the
surface the pointer is confined to will already have received pointer
focus and that the pointer will be within the region passed to the
request creating this object.
...and on region update:
If warped, a wl_pointer.motion event will be emitted, but no
wp_relative_pointer.relative_motion event.
Prior to this patch, sway did neither, and updated the hardware cursor
position without notifying the underlying surface until the next motion
event. This led to inconsistent results, especially in applications that
draw their own software cursor.
Currently, when tablet input exits a window during an implicit grab, it
passes focus to another window.
For instance, this is problematic when trying to drag a scrollbar, and
exiting the window — the scrollbar motion stops. Additionally,
without `focus_follows_mouse no`, the tablet passes focus to whatever
surface it goes over regardless of if there is an active implicit.
If the tablet is over a surface that does not bind tablet handlers, sway
will fall back to pointer emulation, and all of this works fine. It
probably should have consistent behavior between emulated and
not-emulated input, though.
This commit adds a condition for entering seatop_down when a tablet's
tool tip goes down, and exiting when it goes up. Since events won't be
routed through seatop_default, this prevents windows losing focus during
implicit grabs.
Closes#5302.
Keyboard group keyboards should not call sway_keyboard_configure. They
do not have an input config and they derive their state from the
keyboards within the group.
For some reason, I got sway_keyboard_configure and
seat_configure_keyboard mixed up and thought seat_reset_device called
the latter.
Calling sway_keyboard_configure with a keyboard group's keyboard is not
supported and can cause issues. If any clients are listening to the ipc
input event, a sigsegv will occur due to not every property - such as
identifier - being wired up for keyboard group keyboard's.
This also adds an assertion to sway_keyboard_configure to ensure that
this does not occur in the future and any instances are quickly caught.
If the keyboard that triggers the reload binding is using the default
keymap, default repeat delay, and default repeat rate, the associated
keyboard group is never being destroyed on reload. This was causing the
keyboard group's keyboard not to get disarmed and result in a
use-after-free in handle_keyboard_repeat.
If the keyboard was not using the defaults for all three settings, then
it's associated keyboard would get destroyed during the reset - which
did disarm the keyboard group's keyboard. In this case, the
use-after-free would not occur.
This adds a block to input_manager_reset_all_inputs that resets the
keyboard for all keyboard groups in all seats, which will disarm them.
Since the inputs are all being reset anyway, which will reset all
individual keyboards, it is not necessary to be selective on which ones
get reset.
Add a separate per-view shortcuts_inhibitor command that can be used
with criteria to override the per-seat defaults. This allows to e.g.
disable shortcuts inhibiting globally but enable it for specific,
known-good virtualization and remote desktop software or, alternatively,
to blacklist that one slightly broken piece of software that just
doesn't seem to get it right but insists on trying.
Add a flag to sway_view and handling logic in the input manager that
respects that flag if configured but falls back to per-seat config
otherwise. Add the actual command but with just enable and disable
subcommands since there's no value in duplicating the per-seat
activate/deactivate/toggle logic here. Split the inhibitor retrieval
helper in two so we can use the backend half in the command to retrieve
inhibitors for a specific surface and not just the currently focused
one. Extend the manual page with documentation of the command and
references to its per-seat sibling and usefulness with criteria.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
This is a small cleanup commit for removing `sway_tablet` parameters
from functions that already accept `sway_tablet_tool`, since the tablet
reference can be accessed through `tool->tablet`.
This commit renames `motion` and `axis` handlers to `pointer_motion` and
`pointer_axis`, respectively, to disambiguate them from their tablet
(and future touch) handlers. `button` is left as-is, as it is generic
across input devices.
This commit moves tablet motion logic into a seatop handler.
As a side-effect of seatop implementations being able to receive
tablet motion events, fixes#5232.
This commit refactors `cursor_rebase` into `cursor_update_image`, and
moves sending pointer events to the two existing call sites. This will
enable this code to be reused for tablets.
Refs #5232
Currently, clients receive wl_data_device::leave events only when the
pointer enters another surface, which leads to issues, such as #5220.
This happens because wlr_seat_pointer_notify_enter() is called when
handling motion events only for non-NULL surfaces.
Fixes#5220
This is a criteria you can use to select windows since commit
484cc189e9 ("Add shell criteria token"), but there's no way to query
it for an existing window. This exposes its value in the output of
`swaymsg -t get_tree`.
`handle_tablet_tool_set_cursor` was copied from input/cursor.c's
`handle_request_set_cursor`, but the focused surface check was not
adjusted appropriately.
Fixes#5257.
Previously in 3de1a39, it "worked by accident" in my testing since the
display being used in `map_to_output` was initialized first (the map
would not be applied because the display hadn't actually come online
yet), and was followed by a second display (at which point the map would
get applied for the first display).
Refs #5231
Fixes#4819.
This commit ensures that `seat_set_focus` is called to transfer focus
when a window is selected via a pen. Previously, it would race with
`node_at_coords`, and only properly transfer focus if its returned
`surface` was NULL.
Some input rules, like `map_to_output`, are dependent on a specific
screen being present. This currently does not work for hotplugged
outputs, or outputs that are processed after the input device is
initially probed.
This commit fixes both cases, by reconfiguring inputs on each output
addition.
Fixes#5231.
This commit refactors `cursor_handle_activity` to also take the idle
source, so that it can be reused for tablet and touch activity.
Previously, the timeouts would be tracked, but the cursor would never be
un-hidden for anything but pointers.
Fixes#5169.
If we started holding the tool tip down on a surface that accepts tablet
v2, we should notify that surface if it gets released over a surface
that doesn't support v2.
Since GTK supports tablet v2, this fixes the common case of starting a
drag over a GTK surface (e.g. scrollbar) and releasing it outside (e.g.
over the gaps between sway containers, or in a terminal).
Refs #5230.
See issue #5228. Currently, WL_OUTPUT_SUBPIXEL_NONE is ignored and
CAIRO_ANTIALIAS_SUBPIXEL is still set. This commit checks if subpixel is
set to none and if so, calls set_antialias with CAIRO_ANTIALIAS_GRAY.
This mirrors the functionality in Mako's
[PR261](https://github.com/emersion/mako/pull/261)
Instead of handling presses and releases on empty workspaces as setting
focus to the workspace, handle releases by notifying the seat of a
pointer action. This way DnDs are correctly released if the button is
released over an empty workspace. This is achieved by removing the early
return and letting the handle_button() call seat_pointer_notify_button()
at the very end.
Fixes#3932