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.
For some reason my version of sway doesn't show workspace names:
$ swaymsg -t get_outputs
Output HDMI-A-1 '(null) (null) (null)' (inactive)
Output HDMI-A-2 '(null) (null) (null)' (inactive)
Which is weird, but it's no reason to crash swaybar. The field is
totally missing from the JSON, so it ends up doing strcmp(NULL, name)
which is undefined behavior.
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`.
Make notifications a separate flag. Personally, I trigger grimshot
myself most of the time (via sway bindsym) rather than by some external
means, so I don't need to be notified of it happening.
However, keep a flag with this functionality there for those scenarios
there it's necessary to inform the user.
Also print the file location when saving the screenshot.
Show the usage output when an invalid command is received. Otherwise
things like `grimshot --help` save a screenshot, which is really
unexpected and hurts users trying to remember the right commands /
arguments.
Due to the date format used, if several screenshots are taken in
succession, each one overwrote the other.
This change set makes each one have a different name to avoid this.
Also avoid using spaces, since many scripts and tools are unhappy with
file names with spaces.
`$XDG_PICTURES_DIR` is a very loosely defined thing; it's a directory
where "pictures" are stored, which no clearer definition.
Some people use it for photographs they take, other use it for images
they save from the internet, and others use it for screenshots.
Having lots of tools save their output there (anything that's an image
goes there) can easily make it a kitchen sink.
To work around this, use `$XDG_SCREENSHOTS_DIR` as a target directory
for screenshots by default. If not-so-standard variable is unset, fall
back to the previous setting; `$XDG_PICTURES_DIR`.
This also drops an external dependency, which was (a) an overkill (b)
not flexible enough.
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
It is common for user to attach a debug log from the Wayland backend
because they are running the command from inside of Sway. This just adds
a note that the debug logs should be obtained from a TTY. Anyone who is
actually using the Wayland or X11 backends and submitting an issue
related to them likely is already familiar with how to obtain a debug
log for the appropriate backend.
