Just because we take a ref on a surface does not
guarantee that it is still usable a second later.
Check if its been destroyed in the meantime.
This is breaking the template tests in ci, since
there is no client behind the Broadway server.
The assumption is that the source device in events
is a slave device, so create pointer and keyboard
devices and use them in events.
This fixes the seat test on Broadway.
GDK backends are expected to keep a references on
their surfaces as long as they are associated with
external resources, and drop it in destroy().
This showed up as criticals in the shortcuts test
which manually creates and destroys surfaces.
If the tablet gets removed/freed while there are pad events in flight,
we leave a dangling pointer from the pad to the tablet, which may
lead to invalid reads/writes when handling the pad event(s).
If you run weston with the headless backend, you get a Wayland
display with no seat, which is just fine by the protocol.
gdk_display_get_default_seat() returns NULL in this case. Various
widgets assume that we always have a seat with a keyboard and a
pointer, since that is what X guarantees. Make things survive
without that, so we can run the testsuite under a headless
Wayland compositor.
In the gtk-demo drag-and-drop demo i can't drag anything, all I get
is:
(gtk4-demo:358993): Gdk-CRITICAL **: 09:36:19.617: Surface 0x7e1bb0 has not been mapped in GdkSeatGrabPrepareFunc
This is because GdkX11Drag.ipc_surface is not considered mapped, even
though we called gdk_x11_surface_show() on it, because the
GDK_SURFACE_STATE_WITHDRAWN flag is still set.
I added calls to gdk_synthesize_surface_state() to match what
e.g. show_popup() and gdk_x11_toplevel_present() does.
Tracking of those broke sometime along the gdk cleanups, so we
started missing some GDK_GRAB_BROKEN events from being emitted
(eg. after a button press/implicit grab triggers an active grab).
Implicit grabs are only added if there's no prior grab (either
implicit through other button presses, or explicit), in order to
keep accounting correct, make those prevail.
Conditionally check whether the Vulkan headers version defines
VK_RESULT_RANGE_SIZE, and avoid using it for version >=140. The
following comming in Vulkan-Headers has removed the enum value:
0c5351f5e9 (diff-4febd94c0666d59030d8b1dd20c72403)
When I removed the 0-termination for the entries for
each keyval, I remove the code initializing the key,
but accidentally left the code that adds it to the
array, so gdk_keymap_get_cached_entries_for_keyval
returns one extra, uninitialized value at the end
of the array. Stop doing that.
