Now that we have multiple master pointers, this call may pick the wrong one.
Instead, pick the GdkWaylandDeviceData from the first device, and pick the
master pointer from there.
The common GDK code accounts for "pointer emulating" touch sequences to be
synchronized with the pointer position by the windowing system.
However on Wayland pointer and touch are completely independent, the backend
attempts to implement pointer emulation, but doesn't account for the
possible crossing events happening when the user switches from pointer to
touch or the opposite.
In order to fix this, and to ensure we don't have to interact with the
master pointer (which backs the wl_pointer), separate the touch interface
to have its own master pointer, and ensure crossing events are emitted on
it, so the picture of an "emulated pointer" is complete above the backend.
Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=750845
We were using that range for the extra buttons after left/right/middle,
while this is harmless for clients not handling extra buttons (we
used to translate those button events into scroll events in x11 anyway)
this will be unexpected for clients that do handle additional mouse
buttons themselves (eg. back/forward buttons present in some mice).
In order to remain compatible with X11, those need to be assigned from
button 8 onwards.
Also, include input.h, and stop using magic numbers here.
https://bugzilla.gnome.org/show_bug.cgi?id=758072
Make sure the wayland backend sets a new geometry when the client
resizes itself, otherwise the compositor won't be notified and may
revert to the old size on state changes.
Thanks to Jasper St. Pierre <jstpierre@mecheye.net> who pointed out the
problem in gtk+.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=755051
If a GtkMenu (or something else that is mapped as a xdg_popup) tries to
use a subsurface window as a parent, it will be terminated by the
compositor due to protocol violation. So to avoid this, if a parent
window is not a xdg_popup or xdg_surface, i.e. a wl_subsurface, then
traverse up the transient parents until we find the right popup parent.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
Tooltips tend to be placed on top of a parent surface with a given
relative coordinate, and without any input focus. So lets map them as
subsurfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Restructure the mapping procedure so that its known up front what the
expected way mapping is to be done (subsurface, popup or stand alone),
and warn if it fails to actually map in such a way (for example a popup
without a parent or device grab, a tooltip without a parent).
https://bugzilla.gnome.org/show_bug.cgi?id=756496
GDK_NOTIFY_ANCESTOR would happen when the pointer crosses across a direct
parent/child. However nonlinear events are more likely, specially when
the pointer moves across toplevels (either different apps, or menus being
popped up over the pointer position).
This makes popping up comboboxes and other menus that fall over the pointer
position possible. With the previous detail the GtkMenu code misinterpreted
the crossing event, making it think the button release coming right after
should dismiss the popup, which made menus just flash on the screen unless
you kept the button pressed.
If the shared context is in legacy mode, or if the creation of a core
profile context failed, we fall back to an EGL context in compatibility
mode.
Since we're relying on a fairly new EGL implementation for Wayland, we
don't fall back to the older EGL API, and instead we always require the
EGL_KHR_create_context extension.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
keyboard_handle_leave() might be called with a NULL surface resource
(for example if the surface was destroyed after the event was sent). If
so, we should still deal with the keyboard focus lost event, otherwise
we will both leak (the keyboard_focus GdkWindow reference) and miss
stopping the key repeat timer.
https://bugzilla.gnome.org/show_bug.cgi?id=755927
gdk_wayland_device_update_window_cursor() is inconsistently returning
TRUE/FALSE, despite the timeout being always replaced for new cursor
frames. This could end up in these timeouts being "leaked" and running
as long as the window has an animated cursor.
Fix this by making it really sure we return G_SOURCE_REMOVE, although
now we keep track of animation delays, so the timeout will be reused
for constant time animations.
Initially the subsurface will be in synchronized mode and we will leave
it like this until the first time the parent surface has been committed.
The reason for this is because the subsurface position will be applied
as part of the parent surface state, and we need to synchronize the
initial position with the initial frame, so that we don't accidentally
draw the subsurface at the default position (0, 0) which would happen in
desynchronized mode if the subsurface content is committed before the
next parent surface commit.
https://bugzilla.gnome.org/show_bug.cgi?id=754839
If we are using gl for drawing, we don't have a shm surface,
so don't assert that we do. Instead, only call shm-specific
apis when they make sense.
This fixes a crash when showing popovers over a GtkGLArea,
as seen in gdkgears.
https://bugzilla.gnome.org/show_bug.cgi?id=754143
When receiving a selection or when a drag icon enter a window, it was
targeted at a specific window. Lets emit the GDK_OWNER_CHANGE event
only for this window, instead of broadcasting.
Broadcasting has some nasty side effects. For example, if there was n
GdkWindows, and one would for every "owner-change" signal handler
receive n signals about the owner being changed.
An example of where this went a bit out of hand was gnome-terminal,
which added one listener per terminal window. This meant that if
one had m number of terminal windows, each time any one would loose or
gain keyboard focus, O(m^2) owner-change events would be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=754158
The code in _gdk_wayland_window_dispose was not safe against
being called twice - it would call g_hash_table_destroy twice
on the known_globals hash table, the second time operating on
freed memory. It was also leaking the list of async_roundtrips.
After fixing both of these issues, the displayclose testcase
now works on Wayland.
We call gdk_wayland_window_hide_surface when the window gets
destroyed, and in this case, the frame clock might not exist
anymore.
This was showing up in the displayclose testcase.
While we do not have subwindows in Wayland, we do create an
artificial root window. When the display is closed, the root
window gets destroyed, causing recursing to be true for the
toplevel windows.
As the protocol is still considered unstable (meaning not backward
compatible), we should, as stated in the protocol, only bind the version
advertised is the version we implement.
https://bugzilla.gnome.org/show_bug.cgi?id=753856
Prior to this patch, the ID of the GtkApplication was always used for
clients which were GtkApplications. This would only be guaranteed to be
correct for D-Bus activatable programs. As a result, all
non-D-Bus-activatable applications would set the wrong ID making the
shell unable to find the corresponding .desktop file.
This change makes it so that the GDK backend always uses the name
passed to g_set_prgname, or the default value if not explicitly set, as
this more often corresponds to the .desktop file.
This means that in order to make D-Bus activatable applications set the
correct application ID, they must, for now, manually call
g_set_prgname() with their application ID (basename of the .desktop
file).
If g_get_prgname() returns NULL, fallback to gdk_get_program_class()
even though it will most likely never be correct according to the
xdg_surface.set_app_id specification.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
wl_log() currently logs using G_LOG_LEVEL_ERROR
(which is fatal). The wayland client library doesn't
expect this behavior. It uses wl_log to log recoverable
errors.
This commit changes the log level to G_LOG_LEVEL_DEBUG
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=753635
On wayland, the gestures protocol defines a wl_pointer_gestures global
object, that will match in number with wl_seats, swipe and pinch
interfaces can be obtained from it, which events are translated into
GdkEventTouchpadSwipe/Pinch events.
Only a drag context which was created with 'drag_begin' will be
guaranteed to have a source window at all times. Thus, in finalize we
cannot assume we can retrieve a GdkDisplay from the source_window
pointer since it may be NULL. Though, the display is only needed for
contexts created via 'drag_begin' thus we can retrieve it after
checking that is the case.
https://bugzilla.gnome.org/show_bug.cgi?id=749339
We need to be mapped to have a gtk_surface and thus be able to do
requests on it so we need to save the modal hint and apply it when we
get mapped so that code that sets the hint before showing a window
doesn't get ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=753138
-1 means that we have no specific preference for an initial
fullscreen monitor, and -1 is less than the number of monitors,
so we would end up accessing invalid memory. Prevent that.
https://bugzilla.gnome.org/show_bug.cgi?id=752875
Prior to this patch, the hotspot would be passed in buffer coordinate
space. Where this were ever tested, i.e. in a patched mutter, the
server interpreted them incorrectly, which meant it went undiscovered.
In the updated mutter patches the incorrect behavior in GTK+ was
discovered due to the behavior in mutter was corrected.
In the themed cursor case, the dimensions were not correctly scaled
either, but this had no negative visible effect because the dimension is
only used for reporting damage tracking, and passing a bigger damage
region than surface has no negative visible effects.
https://bugzilla.gnome.org/show_bug.cgi?id=752616
Under Wayland, fullscreen/maximized windows may not cover the entire
area when a size increment is specified.
Ignore size increments for fullscreen/maximized windows just like most
window managers do under X11 so that windows with size increments can
still be fullscreen or fully maximized under Wayland as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We mistakenly forced the "STRING" type, which was able to confuse higher
layer helpers like gtk_selection_data_get_uris(). This fixes a crash
happening anytime a drop is attempted on a GtkPlacesSidebar.
Currently, due to the lack of progress information in the Wayland DnD
protocol, we assume a DnD operation is finished after the first
data_source.send is finished (It's either that or leaving stuck grabs).
This however breaks previous assumptions that dest widgets can request
the data multiple times, even in response to GtkWidget::drag-motion.
This leaves us with a NULL owner for the DnD atom when we aren't
finished receiving wl_data_source events yet, causing a crash.
This commit fixes the crash, the behavior left is still far from
desirable though...
And force the ungrab on it, instead of the slave, in the case of
local DnD drop. This avoids confusions on the pointer events spawn
from DnD, as GDK doesn't think anymore those are from a slave device.
Most namely, it fixes the stuck grab when finishing DnD on the
same app it was started from.
We currently only hold the last offer received, which is wrong, as both
are independent and have different life cycles.
This means we have to store per-selection wl_data_offer and targets, and
maintain these as appropriate from the clipboard/DnD specific entry points.
This oddly can be reproduced with weston+weston-dnd, when dragging
anything from GTK+ into weston-dnd, it will insist on picking its
custom application/x-wayland-dnd-flower mimetype, and this request
forwarded by the compositor, even if GTK+ didn't announce it on
its wl_data_source mimetype list. (What should probably happen here
is that the request is silenced, and/or weston-dnd picks (null))
This should be harmless, we are leaking though the fd in that case,
because the emission of GdkEventSelection on an unhandled mimetype
results in NOP. In order to avoid this, we should check whether the
mimetype is supported at all on the backend code and possibly close
the fd, this involves storing these in the first place.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
If the other peer requests data too fast (too rare/unlikely though),
we might receive multiple gdk_wayland_selection_request_target() calls
with no ending gdk_wayland_selection_check_write(), in which case the
fd is leaked as no GOutputStream was created to take over it.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
We weren't catching all the places where the AsyncWriteData operation
should be cancelled, which could happen if we repeatedly request the
same target on different fds.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
At the moment we create the AsyncWriteData, the ownership of the
fd is granted to the GOutputStream, and the fd set to -1, so at
this moment we're just silently getting EBADFD.
This partially reverts 25885ca600, the initialization of .fd
to -1 is valid and stays though.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
On X11 this is something the windowing system does for us, which the
wayland backend should emulate, being grabs completely client-side.
So, if the grab and current focus windows differ, make sure we emit
focus/crossing events as it corresponds to the grab device.
This was being done so only on pointers. Internally, a GdkDeviceGrabInfo
is kept for each of the master pointer/keyboard, failing to do this for
keyboards results in a stuck keyboard grab.
https://bugzilla.gnome.org/show_bug.cgi?id=748892
The fd must be closed on async_write_data_free(), but we should also
initialize it to -1 so gdk_wayland_selection_check_write() doesn't wrongly
pick the stdin fd.
https://bugzilla.gnome.org/show_bug.cgi?id=751414
A subsurface positioning operation only takes effect when the parent
surfaces state is applied. If a subsurface is mapped and positioned, but
the parent surface state is not immediately committed, the relative
position of the subsurface is undefined and may be placed incorrectly.
To avoid this undefined state, always request that the parent surface
should be committed after mapping a subsurface so that the position
operation will take effect.
https://bugzilla.gnome.org/show_bug.cgi?id=751098
If a menu was not attached to any widget, we try to calculate its
position given where the grabbed pointer is and what window has its
focus. Previously we failed to do so if a "transfer window" was used
for the grab, and this patch adds a code path that, if the menu window
itself didn't have the grab, look for the transfer window and get the
grab device from there.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
If a position was already explicitly set, don't try to guess the
position of popup menus by looking at the pointer position, just use
the set coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=748951
According to the xdg-shell protocol specification the (x, y) coordinates
passed when creating a popup surface is relative to top left corner of
the parent surface, but prior to this patch, if the parent surface
was an xdg_surface, we'd position it relative to top left corner of the
window geometry of that xdg_surface.
https://bugzilla.gnome.org/show_bug.cgi?id=749717
On wl_keyboard.key/modifiers, we're just forgetting about currently
pressed mouse buttons. Fix this by storing button and key modifiers
separately, and put these together when creating the GdkEvents.
Some features need certain globals to initialize. In order to deal with
these dependencies, add a way to postpone closures that depend on a
certain set of globals, that later will be invoked when required
globals are all received.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
Instead use asynchronous round trips that is synchronized in the end of
the initialization. This makes it easier to track state, as we won't
dispatch arbitrary Wayland messages while processing globals.
https://bugzilla.gnome.org/show_bug.cgi?id=719819
The ordering of globals in connection setup under weston
is different from mutter, and we end up creating a the
dnd window before any outputs are present. Don't cause
a critical warning in that case.
I was getting really weird values for scale for the blank cursor used
when hiding the cursor in a GtkEntry when typing, this was caused
by gdk_wayland_device_update_window_cursor sending random values
when the returned buffer was NULL.
We fix this by just not sending any buffer or scale updates in this
case.
GdkKeymap already has support for _get_num_lock_state() and
_get_caps_lock_state(). Adding _get_scroll_lock_state() would be good
for completness and some backends (Windows?) could take advantage of
this.
Add two new requests to the gtk_surface interface: set_modal and
unset_modal. The server will currently not do anything special with
input focus, and its up to the client to ignore events on the parent
surface.
This commit bumps the gtk_shell interface version to 2. By connecting to
a Wayland server with another gtk_shell interface version any features
depending on the gtk_shell protocol will not be available.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
gdk_wayland_drop_context_set_status() can't do much else currently besides
picking a mimetype (the first one is currently chosen). This may incorrectly
unset the mimetype chosen on .receive(), so the transfer is cancelled before
it even starts.
At the time drop_reply happens, we should have already picked a mimetype
along the way, so only cover for accepted=FALSE in order to unset it.
During drag operations from another client, we currently set no window as
the DnD source. There's paths in upper layers though that rely on it being
set, just that we don't trigger these yet.
When we open the connection, we get the wl_output object,
but we return before all the information such as monitor
geometry has arrived, which causes us to misinform early
users of this information. Do a roundtrip here that causes
us to wait until the information is complete. Do the same
for seats, just in case.
https://bugzilla.gnome.org/show_bug.cgi?id=747471
The "app_id" of a xdg_surface should be the ID that can potentially be
used to get the DBUS name or the .desktop file.
For GtkApplication programs this is often the ID passed when creating the
GtkApplication object, so when available lets use that.
As fallbacks, first try g_get_prgname as it often corresponds to the
basename part of the .dektop file for non-GtkApplication programs.
Otherwise use gdk_get_program_class, even though that string usually
doesn't conform to the expectations of xdg_surface.set_application_id.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
During copy/paste, it may be common that we receive several property changes
around the selection atom, this results in warnings when cancelling the previous
write attempt. We already honor the last request properly, so we should just
cancel silently.
The wl_data_source may be the clipboard's. Looking up the drag context in
order to get the display isn't going to fare well there. So, just use the
default display, and only look up the drag context when we know we need it.
https://bugzilla.gnome.org/show_bug.cgi?id=746386
Support scaling of cursors created from themes. The default scale is
always 1, but if the pointer cursor surface enters an output with a
higher scale, load the larger version of the cursor theme and use the
image from that theme.
This assumes the theme size is set to one that fits with an output scale
= 1.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
The setting of the the surface scale even when the surface is not
created from a surface was introduced due to a crash when getting the
buffers when dividing by the scale. The only reason I can see this is
that we get the buffer from a non-existing surface when the wl_cursor
has not yet been set.
Instead, use the name field to avoid trying to use the non-existing
surface, effectively avoiding the division-by-zero that way.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
The gtk-shell Wayland protocol extension is not meant to be backward
compatible right now, so avoid binding to any version that is not the
one supported.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
When a window is hidden, its surface and all its roles are destroyed,
if this happens when we already issued a wl_surface_commit and are
awaiting for a frame callback, the clock will remain frozen for the
next time the window is shown.
To avoid this, keep track of the wl_surface_frame() calls issued,
and ensure the clock is thawed after hiding. If we happen to receive
the frame callback, it is just ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=743427
We were just throwing the request away if the app asks to
fullscreen or maximize a window before it has been mapped.
This is something the GdkWindow API explicitly supports,
so make it work by saving the state until the surface exists.
This fixes things under weston. There are bugs in mutter
that keep this from working correctly with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
