To prevent wl_keyboard keymap being written to by clients, use a unique
file descriptor for each wl_keyboard resource.
Reference: weston, commit 76829fc4eaea329d2a525c3978271e13bd76c078
sx, sy used to store the buffer offset of the drag surface which was
then be added (by rootston) to the drag icon position.
Buffer offsets are handled already in surface_intersect_output
(output.c) so they were added twice for dnd surfaces.
This is so we can potentially add comments to it, and so if a user looks
at the installed header, they can see the /* #undef WLR_HAS_FEATURE */
line to see every option, even if not available.
Implement the tablet-v2 tablet tool's implicit grab semantics for
buttons and tip.
This avoids losing focus (to other [sub]surfaces) when a button is held,
or the tip is down.
This should help when the device is used close to a surface's border and
would otherwise have to be very precise.
This introduces -DWLR_USE_UNSTABLE and adds information regarding the
stability status to all headers. I started with a conservative set of
headers to mark as stable:
- types/wlr_matrix.h
- util/edges.h
- util/log.h
- util/region.h
- xcursor.h
153f37bdf5 (#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.
This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.
The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.
A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is https://github.com/swaywm/sway/issues/2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
Implement the basic logic for tablet-v2 tablet_pad's grabs. And plug in
the default grab.
Features like "holding" the focus should be implemented via grabs, like
they are for pointer and keyboard.
The override_redirect flag can change on configure notify and
on map notify. This adds an event to know when it changes.
This removes wlr_xwayland_surface_is_unmanaged which was wrongly
using the window type to decide whether the view should be
unmanaged.
A similar patch was proposed to Weston, but has never been
merged upstream [1].
[1]: https://patchwork.freedesktop.org/patch/211161/
There were a few issues after rebase, that the merge algorithm didn't
throw at my face:
wlr_output did a check on the actual role, not a string anymore, so that
had to go to allow tablet-v2 to set cursor surfaces.
A few L_DEBUG/L_ERRORs were still around
There was a user-after-free in tablet-group free()ing, probably after
insufficient testing from a previous feedback pass
The previous naming was based on the input-device capability names from
libinput.
With code that uses the libinput_tablet_tool and mapping into tablet-v2,
this is confusing, so the name is changed to follow the names used in
the protocol.
random human
Drew DeVault
emersion
nyorain
Ryan Dwyer
Ilia Bozhinov
Alexander Bakker
Brian Ashworth
Armin Preiml
Scott Anderson
Markus Ongyerth