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
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
Before this patch, we'd always allocate a full size SHM buffer via
the wl_shm_pool, even though it would never be used. Instead allocate a
logical 1x1 cairo image surface.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
In order to support window scales for EGL windows, resize the
wl_egl_window to the window dimension multiplied with the window scale,
just as with SHM window buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
When the preferred surface scale changes, for example when entering a
wl_output with a higher scale than any previous entered output, recreate
the shm surface and redraw the window content with the new window scale.
Before this patch, the internal scale would be changed, but the shm
surface would not be recreated given the new scale, i.e. we'd attach a
buffer for a different scale than wl_surface.set_scale specified.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
If the compositor is too old for handling surface buffer scales, never
tyr to set change it. This will effectively always leave it to its
initial state, i.e. 1.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
It will be useless to check the source window on the destination side,
it's at the moment always NULL. Fetch the display from the device instead,
which will be set for every GdkDragContext.
Some compositors might not offer wl_seat 4 resulting in GTK+ clients not
working on that compositor.
wl_seat 4 introduces keyboard repeat information, but when that information
is missing it is retrieved from settings, hence there's no reason to
require wl_seat 4.
This patch was tested against QtCompositor (5.5, dev branch)
and Weston 1.6.1.
Reviewed-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744172
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.
Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.
https://bugzilla.gnome.org/show_bug.cgi?id=744407
Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.
One of the major requests by OpenGL users has been the ability to
specify settings when creating a GL context, like the version to use
or whether the debug support should be enabled.
We have a couple of requirements in terms of API:
• avoid, if at all possible, the "C arrays of integers with
attribute, value pairs", which are hard to write and hard
to bind in non-C languages.
• allow failing in a recoverable way.
• do not make the GL context creation API a mess of arguments.
Looking at prior art, it seems that a common pattern is to split the
construction phase in two:
• a first phase that creates a GL context wrapper object and
does preliminary checks on the environment.
• a second phase that creates the backend-specific GL object.
We adopted a similar pattern:
• gdk_window_create_gl_context() creates a GdkGLContext
• gdk_gl_context_realize() creates the underlying resources
Calling gdk_gl_context_make_current() also realizes the context, so
simple GL users do not need to care. Advanced users will want to
call gdk_window_create_gl_context(), set up the optional requirements,
and then call gdk_gl_context_realize(). If either of these two steps
fails, it's possible to recover by changing the requirements, or simply
creating a new GdkGLContext instance.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Use xdg_surface_set_window_geometry() to tell the compositor about the
shadow widths, this makes some gnome-shell/mutter features (edge resistance,
frames around windows in the overview, side maximization, ...) work alright
with GTK+.
In order to add this, some other places in gdkwindow-wayland had to gain
some knowledge about margins:
- xdg_surface_configure() now syncs the shadow after applying the state,
and gdk_wayland_window_set_shadow_width() possibly reconfigures the
window in order to preserve window geometry. This is necessary to keep
shadows in sync with state/geometry changes, as this does not happen
all at once.
- xdg_popups relative to an xdg_surface are shown relative to buffer
coordinates, so the left/top margins must be added there.
https://bugzilla.gnome.org/show_bug.cgi?id=736742
It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.
Instead of possibly calling wl_surface_commit() out of
GdkFrameClock::after-paint, tick the transient parent clock so ::after-paint
can be eventually run.
This ensures that the subsurface coordinates (considered part of the state
of the parent) aren't committed untimely, and guaranteed to be orderly with
the wl_subsurface-relative state.
This is a gtk-side fix for https://bugzilla.gnome.org/show_bug.cgi?id=738887
