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
When the Wayland compositor vanishes, all applications connected will
receive a SIGPIPE as soon as they try to use wl_display_dispatch().
Do not use g_error() to terminate the applications when this occurs,
g_error() means an error in the application while here it's not truly
the case.
Use g_warning() and exit() instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=745289
