Only set input, opaque and window geometry regions once per commit.
They are double buffered anyway, so the last one would only take effect
either way; this way reading protocol logs are much more pleasent.
https://bugzilla.gnome.org/show_bug.cgi?id=769937
The wayland tablet protocol allows notifying the compositor with
descriptions of the actions performed by each tablet element. This
API call allows to hook up in to this wayland-specific feature.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
These devices are kind of an strange case. Their "master" device is
the keyboard, because they share toplevel focus with it, regardless
of stylus focus. Nonetheless, they are only expected to send the
GdkEventPad* set of events.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
This is a subclass of GdkWaylandDevice that implements GdkDevicePad,
all pad features are looked up from the info obtained through the
tablet v2 interface.
https://bugzilla.gnome.org/show_bug.cgi?id=770026
An xdg-popup requires a serial that the compositor will compare against
its own serial and will dismiss the popup if it doesn't match.
gtk+ uses either a pointer or touch serial for its helper function
_gdk_wayland_seat_get_last_implicit_grab_serial() but if the menu is
triggered before the user has had any pointer or touch interaction with
the client, using a keyboard shortcut, there is neither pointer nor
touch serial available, and gtk+ will use 0 as the default.
As a result, the compositor will instantly dismiss the xdg-popup. In
this case, gtk+ should use the keyboard serial instead.
Track keyboard serial as well and use the keyboard serial as the value
if there is no newer pointer or touch serial available.
https://bugzilla.gnome.org/show_bug.cgi?id=768017
At the time of move_to_rect() is called, not all state may have been set
up on the impl gdk window, causing the position to sometimes be
slightly offset due to drap shadow margins. For now, work around this
by postponing the processing of the move_to_rect() parameters until
showing, when its more likely that all state (such as shadow margin)
has been set correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
The position of each transient-of will be in fake-root coordinate
space; thus we should not accumulate all the positions making it an
offset; each window is already in fake root coordinate space.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
When using the set transient-for as a popup parent, fetch the effective
toplevel instead, otherwise we will position against the wrong
coordinate.
https://bugzilla.gnome.org/show_bug.cgi?id=769402
This matches the behaviour of Mutter, Metacity and traditional X11
window managers on the window manager side, and is what we want
for at least gnome-terminal. I can't think of any reason why we'd
want incremental resize in any other tiled window.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=760944https://bugzilla.gnome.org/show_bug.cgi?id=755947
Only update to using v2 headers/structs. The incompatible changes
to tool events are dealt with in the next commit. Pads aren't handled
in this commit either.
On X11, device_query_state() uses XIQueryPointer() which will return a
child window only if the pointer is within an actual child of the given
window.
Wayland backend would return the pointer->focus window independently of
the given window, but that breaks the logic in get_device_state() and
later in gdk_window_get_device_position_double() because the window is
searched based on coordinates from another window without sibling
relationship, breaking gtkmenu sub-menus further down the line.
Fix the Wayland backend to mimic X11's XIQueryPointer() to return a
child only if really a child of the given window.
That's the most sensible thing to do to fix the issue, but the API here
seems to be modeled after the X11 implementation and the description of
gdk_window_get_device_position_double() is not entirely accurate.
https://bugzilla.gnome.org/show_bug.cgi?id=768016
This has most notably impact in selection buffers, because those were
shared across all selection atoms. This turned out wrong on 2 situations:
- Because the selection atom was set at SelectionBuffer creation time, the
GDK_SELECTION_NOTIFY events generated will have unexpected info if the
buffer is attempted to be reused for another selection.
- Anytime different selections imply different stored content for the same
target.
This is better separated into per-selection buffers, so it's not possible
to get collisions if a same target is used across different selections.
https://bugzilla.gnome.org/show_bug.cgi?id=768177
The sanitize_utf8() function has been copied from X11 so both
backends behave the same. This allows interaction with older clients
(mainly through Xwayland, and the STRING selection target) that
request non-utf8 text.
https://bugzilla.gnome.org/show_bug.cgi?id=768082
Debian stable currently ships with a 3.16 kernel, so
it doesn't have memfd available.
This commit adds shm_open fall back code for that case
(for now).
https://bugzilla.gnome.org/show_bug.cgi?id=766341
We currently use syscall() directly to invoke memfd_create,
since the function isn't available in libc headers yet.
The code, though, mishandles how errors are passed from syscall().
It assumes syscall returns the error code directly (but negative),
when in fact, syscall() uses errno.
Also, the code fails to retry on EINTR.
This commit moves the handling of memfd create to a helper function,
and changes the code to use errno and handle EINTR.
https://bugzilla.gnome.org/show_bug.cgi?id=766341
A wl_buffer has a max size of 4096 bytes, of which 8 are needed for the
header and another 4 for the string argument length (in this case), so
make sure the we only save the first 4083 bytes that are still valid
UTF8.
https://bugzilla.gnome.org/show_bug.cgi?id=767241
xdg-shell allows desktop environments to extend the list of states
within a given range.
Use this possibility to add a new state for tiled so that gtk+ can
benefit from this.
https://bugzilla.gnome.org/show_bug.cgi?id=766860
The Wayland protocol does not share XI2's wealth of information
about individual devices, but it does provide discriminating
information about the source for scroll events. Pass this on to
the application by creating separate slave devices for these,
and setting them as source device on the scroll events.
These devices can be discriminated by their input-source property:
wheel - GDK_SOURCE_MOUSE
finger - GDK_SOURCE_TOUCHPAD
continuous - GDK_SOURCE_TRACKPOINT
https://bugzilla.gnome.org/show_bug.cgi?id=767093
fix up
Given that Wayland has no global coordinate, the only way for gdk to
retrieve the monitor a window last entered is to retrieve it from the
GdkWaylandWindow itself.
Implement the backend specific get_monitor_at_window() to return the
monitor that was last entered by the window.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.
Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.
https://bugzilla.gnome.org/show_bug.cgi?id=766566
Only generate crossing events on wl_touch.down for the virtual master
device used for touch events, and only whenever this virtual device
actually moves across surfaces. This behavior resembles better what is
expected in X11, where the pointer is warped to the touch position
on XITouchBegin.
This avoids the double emission of leave events when the pointer
emulating touch is lifted, that crossing event will be instead
generated when/if the focus surface changes.
https://bugzilla.gnome.org/show_bug.cgi?id=766314
This is required for proper integration with any other library/application that
may perform wayland API calls and poll() the wayland fd from multiple threads.
Using wl_display_dispatch{_queue}() is thread-safe if not mixed with custom
poll() usage, which GSource/GMainContext does.
Essentially, the problem is that multiple threads polling and reading
the same fd is extremely racy. Use the wayland provided API for allowing
concurrent access to the wayland display fd.
See the wayland man pages for wl_display_prepare_read(),
wl_display_cancel_read() and wl_display_read_events() for more details.
https://bugzilla.gnome.org/show_bug.cgi?id=763852
