When GDK_DEBUG=no-vsync is on, we might have more than one outstanding
frame. Don't assert when that hapens. Just request a frame callback for
the first and skip the others.
... when it is available.
Also introduce the new function gdk_rectangle_transform_affine(), which
looks like overkill for this purpose, but I'm about to use it elsewhere.
There's no need for EGL to do any timing, we do it in GTK already.
This fixes hangs in Mesa when we hide a surface after a SwapBuffers()
but before the frame callback arrives.
If we then reshow the surface and immediately render to it, Mesa would
still have a frame callback from before the hiding and forever poll()
waiting for the compositor to send the callback.
Fixes#5761
That way, it doesn't ned a specific init function.
Also chain up last, so that the generic initialization code can access a
fully initialized wayland surface.
X11 does add an extra reference to surfaces that gets released when the
DestroyNotify event arrives.
Wayland doesn't ave such an event, so that reference never gets
released.
This fixes a copy/paste error introduced in commit 590f3dfa1f.
We want to remove the event queue from the list of event queues, not the
surface.
Otherwise the freed queue stays in the list and the next time an event
comes in, we access invalid memory.
Fixes thinko introduced in commit 7fafa5133b.
Luckily, we leak all surfaces, so this problem never occured.
We want to keep the wl_surface around, because surfaces create their
resources on construct and keep them until destroyed. See the HWND ond
Windows and the XWindow on X11.
This is relevant for graphics resources, where we want to have access
to the VkSurface and eglSurface while the GdkSurface is hidden.
We also want these surfaces to be permanent and not change during the
lifetime of the GdkSurface.
What we can - and must - destroy however are the xdg surfaces, because
those handle visibility on screen.
And we also need to ensure no buffer is attached, so that during the
next creation of the xdg surface we don't get a protocol error.
gdk_wayland_surface_maybe_resize() just calls
gdk_wayland_surface_update_size(), so make all callers call that one
instead.
The check that it does is done by the other function again.
This workaround - were it ever to trigger - is broken today. It destroys
the wl_surface and all associated structs but does not recreate the
xdg_popup or xdg_toplevel struct, so it would cause a hidden window.
The workaround looked a lot different when it was introduced in commit
83b54bab57, too - both in what it did and
in what the vfuncs did that it called.
When grabbing the seat for an xdg popup using xdg_popup_grab() in response
to a touch-end event, we request the grab a little late and the touch is no
longer being tracked by gdkseat. This means that
_gdk_wayland_seat_get_last_implicit_grab_serial() right now can not provide
us with the serial for that touchpoint, because that serial was stored on
the GdkWaylandTouchData that is already gone.
To still provide the compositor a valid serial in that case, store the
serial of the latest touchpoint more persistently in GdkWaylandSeat itself,
so that we can still access it when the touchpoint has already ended.
Fractional scaling with the GL renderer is
experimental for now, so we disable it unless
GDK_DEBUG=gl-fractional is set.
This will give us time to work out the kinks.
This commit combines changes in the Wayland backend,
the GL context frontend, and the GL renderer to switch
them all to use the fractional scale.
In the Wayland backend, we now use the fractional scale
to size the EGL window.
In the GL frontend code, we use the fractional scale to
scale the damage region and surface in begin/end_frame.
And in the GL renderer, we replace gdk_surface_get_scale_factor()
with gdk_surface_get_scale().
Cairo can do that, so just enable it:
* Create surfaces with the correct fractionally scaled size.
* Set the Cairo surface's device scale to that number.
Instead of setting the buffer scale via the buffer-scale command, set it
via the viewport.
This technically allows setting fractional scales, but we're not doing
that.
April fools!
No, really.
The fractional scale protocol is just a way to track the surface scale,
but not a way to draw fractional content.
This commit uses it for that, so tht we don't rely on tracking outputs.
This also allows magnifiers etc to send us a larger (integer) scale if
they would like that, that is not represented by the outputs.
Add a new flag to track whether buffer scale is dirty or not,
and centralize calling wl_surface_set_buffer_scale() in a single
place: gdk_wayland_surface_sync_buffer_scale().
gdk_wayland_surface_sync_buffer_scale() is only called by
gdk_wayland_surface_sync(), which itself is called by the GL,
Vulkan, and Cairo contexts, right before submitting a frame.
This ensure that each frame has an up-to-date buffer scale.
This mimics how opaque and input regions are tracked.
If we map, reposition, unmap, remap, the reposition feedback from the
last time a popup was mapped might be received while we're dealing with
the new version of the popup. At this point, the old reposition token
has no meating, so lets drop it. Also reset the reposition tokens when
creating new protocol objects, so that the reposition token are as if
we're in the initial state.
This fixes an issue where we'd get stuck if repeatedly smashing a button
that'd create popups that'd immediately get dismissed by the compositor.
Since Wayland 1.15, it is now possible to use absolute paths in
"WAYLAND_DISPLAY".
In that scenario, having a valid "XDG_RUNTIME_DIR" is not a requirement
anymore.
For this reason we remove the "XDG_RUNTIME_DIR" check and we let
`wl_display_connect()` decide if our environment is correct.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
The cursor-theme-size setting is documented as
'0 means the default size'. Make it so by using
size 24 if we see a 0. Its better than crashing.
Fixes: #5700
Otherwise GL surfaces that redraw without changing the hotspot have it
applied on top every frame and quickly slide away.
The cairo path and the X11 backend do not have this bug.
GdkDragSurface-backed widgets are not parented to an existing widget,
unlike popovers, and like toplevels. This means that there's nobody to
actively call gdk_drag_surface_present() to update the size, and
GdkDragSurface should do it on its own, just like GdkToplevel.
This commit implements this for the Wayland backend.
The split-up of gdksurface-wayland.c introduced a protocol violation
when it didn't make sure xdg_surface was destroyed after the role
objects (xdg_popup / xdg_toplevel). Fix that.
Fixes: 2a463baed0 ("wayland: Rearrange the surface code")
The availability of wl_surface.offset depends on the compositor, so we
can't call it unconditionally. Add a version check to so we only call
offset if we know we won't raise a protocol error.
Fixes: 0eb791eaaa ("Make mask nodes more versatile")
This is a bit spaghetti right now, since seats and devices were
heavily entangled there are a number of crossed private API calls that
should ideally not be there.
Let this be a first step, so more bits may move from the seat
implementation to devices.
This file, event though a clump of input-y objects, has more of
seats than anything else. Rename it so that we can start splitting
these objects out of it.
This is currently just used as a convenience storage of the startup ID
between the GtkApplication and the GtkWindow (after it's ready to notify
on it).
This could be untangled in the GTK layers so there is no involvement
from GDK in keeping the startup ID around, in the mean time just deprecate
these gdk_wayland* API calls.
This call has everything to perform activation as specified by the
xdg_activation protocol, notably a surface to activate as opposed to
gdk_display_notify_startup_complete().
Make activation happen here, so that the surface gets activated when
its gets a startup ID assigned.
The argument to xdg_activation_token_v1_set_surface is documented to be the
surface requesting the activation, not the surface to be activated, which is
given later when calling xdg_activation_v1_activate.
(c.f. 36cee4bdbc)
Use the same logic as in gdk_wayland_app_launch_context_get_startup_notify_id,
i.e. if we have a surface with focus, set that, otherwise set NULL.
This fixes requesting urgent/focus on wlroots (compositors like Sway, etc.),
which was blocked as the surface requesting the activation didn't have focus.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
By using wl_output_release(), GDK lets the compositor to clean up the
output global more nicely.
For example, currently, most compositors remove the global and then
destroy it later after N seconds expire. With this, the compositor could
experiment with destroying the output global once all its resources are
destroyed.
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.
This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5250
We shouldn't assume there is always a monitor to derive bounds from.
If there is no monitor, pass empty bounds, as this matches what
xdg_toplevel.configure_bounds do in this case.
As far as I'm aware, these only exist with `gdk_wayland_surface_` names
for historical reasons, before these types were split.
This way, those functions will be able to access members of the
`GdkWaylandToplevel` struct. And it just saves a few lines of code.
`apply_monitor_change()` already calls `update_scale()`.
Note that this only affects old compositor versions (see
`should_update_monitor()`) so it's just a minor cleanup.
Starting with the Wayland protocol wl_pointer >= 8, discrete axis
events have been deprecated in favour of high-resolution scroll event.
Add a listener for high-resolution scroll events and, for backwards
compatibility, handle discrete events as discrete*120.
Even though the argument is non-nullable, GTK sometimes incurs in that
by itself by destroying the surface while the event is in flight. This
is the case of popping down a GtkDropdown. When this happens we simply
ignore the crossing event, but we should let it through instead, the
compositor did not send it in vain and we possibly still have pointer
state to undo.
Drop the surface checks, so that the event is propagated along GTK.
Following what was done for pinch/swipe events, give hold gestures their
own distinct sequence as well. Without this it was NULL, which was already
distinct to other touchpad gestures.
This serial should be that from a button press/touch down/etc, use
the last implicit grab here, which will presumably be from the same
device that triggered the event.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5048
The GdkToplevelSize struct already has the concept of "bounds", which
means the largest size a window should reasonably have. It's practically
the equivalent of the monitor the window is intended to be mapped on,
with the "struts" (e.g. panels) cut out. It's used by GTK to use this
information to calculate a default window size that is "lagom" (swedish;
not too large, not too small).
When loading cursors at scale, we expect the
cursor images to have a size of scale * size.
If we don't find such images, load them at their
unscaled size and scale them up ourselves.
Without this, cursors will appear in unexpected
sizes depending on scales and themes.
Related: #4746
On Wayland it is a protocol violation to upload buffers with
dimensions that are not an integer multiple of the buffer scale.
Until recently, Mutter did not enforce this. When it started
doing so, some users started seeing crashes in GTK apps because the
cursor theme ended up with e.g. a 15x16 pixel image at scale of 2.
Add a small sanity check for this case.
Previously, there was an issue with glitching after showing/hiding a
popover that was not also destroyed. This was due to the popover having
an update_freeze_count of zero after hiding the surface.
That resulted in it's toplevel continuously dropping frames such as during
high-frame-rate scrolling in textviews. This problem is much more visible
on high-frame-rate displays such as 120hz/144hz.
With this commit, we freeze the frame clock of the popup until it is
mapped again.
Add a new GdkScrollUnit enum that represent the
unit of scroll deltas provided by GdkScrollEvent.
The unit is accessible through
gdk_scroll_event_get_unit().
Currently, we have all the plumbing in place so that GTK consumes the
startup notification ID when focusing a window through the xdg-activation
protocol.
This however misses the case that a window might be requested to be
focused with no startup ID (i.e. via interaction with the application,
not through GApplication or other application launching logic).
In this case, we let the application create a token that will be
consumed by itself. The serial used is that from the last
interaction, so the compositor will still be able to do focus prevention
logic if it applies.
Since we already do have a last serial at hand, prefer xdg-activation
all the way over the now stale gtk-shell focusing support. The timestamp
argument becomes unused, but that is a weak argument to prefer the
private protocol over the standard one. The gtk-shell protocol support
is so far left for interaction with older Mutter.
Tools like gtk4-launch can't set surface on the activation token so
don't require it. If the compositor requires it we can't do anything
about it anyway. This avoids a critical:
(gtk4-launch:23497): Gdk-CRITICAL **: 17:07:24.704: gdk_wayland_surface_get_wl_surface: assertion 'GDK_IS_WAYLAND_SURFACE (surface)' failed
Fixes: be4216e051 ("gdk/wayland: Support the xdg-activation wayland protocol")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
We only save the size when we transition from floating to fixed, so that
we can restore the size to the one prior to being fixed.
However, we should not restore to this size whenever we see a 0x0 size
from xdg_toplevel, as it can do that any time it doesn't care about the
size, e.g. when the surface is floating and just changing state.
Fix this by only using the saved size when transitioning from fixed to
floating, not when staying floating while previously floating.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4634
gdk_wayland_toplevel_inhibit_idle() contained a contradictory assert
that always fail. More specifically, in the branch that is supposed to
create the idle inhibitor, there is an assertion that it must already
exist and that the refcount must be greater than zero. This causes a
crash on WMs/DEs that use the ZWP idle inhibit manager protocol such as
KDE Plasma and Sway. Fix this by just asserting that the refcount is
zero instead.
This makes the hotspot of DND surfaces work when using the Vulkan and
OpenGL renderers.
This bumps the CI image used to the newly built image. This is needed to
install a new enough libwayland-client.so needed for wl_surface.offset.
This is done by adding wayland as a meson subproject, building it
on-demand if the version in the system is not new enough. As
libwayland-client.so is pulled in implicitly when linking to gtk4, the
compile step needs LD_LIBRARY_PATH set to make ld find the right library
to link to.
If we ended up on no output at all, keep the HiDPI scale as is, as it
likely means we were on a workspace that was switched away from. By
keeping the same scale, we avoid unnecessary scale changes that would
otherwise take place if the scale when on monitors would end up being
more than 1.
We now have a boolean setting that determines whether the high-contrast
theme should be used. Support it by automatically setting the existing
`gtk-theme-name` and `gtk-icon-theme-name` properties when enabled.
With that, it is no longer necessary to change the regular theme settings
for high-contrast, so toggling between high-contrast and a non-default
theme finally works reliably.
It makes sense to connect the begin/update/end events
for touchpad swipes and pinches in a sequence. This
commit adds the plumbing for it, but not backends
are setting sequences yet.
In some circumstances (e.g. activating with a stylus something that
closes a window), we can receive zwp_tablet_tool.proximity_out without
receiving a zwp_tablet_tool.up beforehand.
In those cases, we are not expecting neither .up nor .button, so
reset the stylus device button modifiers on proximity_out.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4103
We are looking up the seat logical pointer modifiers (i.e. the wl_pointer),
not the ones for the tablet tool device. This breaks accounting further
along in GTK leaving stuck implicit grabs.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4102
As far as I can tell, the code here is redundant and probably ended up
this way for historical reasons. A drag surface without
`->is_drag_surface` would be created if `gdk_display_create_surface`
were called with `GDK_SURFACE_TEMP`, but drag surfaces never seem to be
created that way.
In `gtk4-demos`, drag and drop and popovers seem to be working normally
with this.
Ping/pong serials are not meant to be interpreted as user input serials
(e.g. those given back later to the compositor on grabs). As a matter
of fact, Mutter uses a different count (i.e. timestamps) in these, so
using these serials may confuse the compositor into denying certain
operations like DnD.
Instead of using GL_BACK, use GL_BACK_LEFT, because the spec demands
this (many drivers don't).
Also move the call from the GDK backends into the GLContext code, as
this is a generic EGL issue (nvidia being the main driver in need of
this call, see 9c4c4eaaa1 for a longer
discussion).
Fixes#4402
Otherwise if we hide and show a window we recreate a new surface,
breaking the compositor's association, but potentially not resend this
data for the new surface.
This matches what we do for input_region.
The term "hdr" is so overloaded, we shouldn't use them anywhere, except
from maybe describing all of this work in blog posts and other marketing
materials.
So do renames:
* hdr => high_depth
* request_hdr => prefers_high_depth
This more accurately describes what is going on.
Unify the X11 and Wayland EGL contexts.
This is a bit ugly to implement, because I don't want to create an
interface and I can't make them inherit from the same object, because
one needs to inherit from X11GLContext and the other from
WaylandGLContext.
So we have to put the code in GdkGLContext and make sure non-EGL
contexts can't accidentally run it. This is rather easy because we can
just check for priv->egl_context != NULL.
Print the extensions one per line, and sort them
alphabetically, so it is actually possible to find
something in the list.
Also print a short description of the chosen config.
Creative people managed to create an X11 display and a Wayland display
at once, thereby getting EGL and GLX involved in a fight to the death
over the ownership of the glFoo() symbolspace.
A way to force such a fight with available tools here is (on Wayland)
running something like:
GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo
Related: xdg-desktop-portal-gnome#5
