Logging them with `g_print()` will write to stdout, which can interfere
with machine-readable output, for example when gnome-control-center
displays the GPU/driver name.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/7093
Signed-off-by: Simon McVittie <smcv@debian.org>
With the swapchain maintenance extension, we have a way to release
the acquired swapchain image before recreating the swapchain, in
the VK_SUBOPTIMAL_KHR case. Use it.
Tested by toggling fullscreen in the bloatpad example, which causes
mesa to return VK_SUBOPTIMAL_KHR (since dmabuf modifiers change).
If vkAcquireNextImageKHR returns VK_SUBOPTIMAL_KHR, the semaphore
is in use, but vkDeviceWaitIdle will not wait for it, since it is
not associated with a queue. Make sure that is the case, so we don't
run into a validation error when we try vkAcquireNextImageKHR with
the same semaphore, after recreating the swap chain.
See https://github.com/KhronosGroup/Vulkan-Docs/issues/1059 for
some related discussion.
Fixes: #7079
This is an upstream protocol providing equivalent functionality as the
system bell request in gtk-shell.
This commit includes a copy of xdg-system-bell-v1.xml, since we don't
depend on wayland-protocols 1.38 yet.
It seems that NVidia sets PFD_SWAP_EXCHANGE / WGL_SWAP_EXCHANGE_ARB
on pixel formats but doesn't guarantee that the backbuffer age is
constantly 2. My guess is that they use swap exchange only to signal
usage of a flip present method.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/7019
We get to create our GdkKey with a display as a property for free, so
just stuff the default keymap and keymap serial (to track IME state
changes and so) into our GdkWin32Display under an existing sub-struct
that is for holding these items.
On Windows, we really only support a single GdkDisplay, so we can just
make the GdkDisplay that we obtain a property of our GdkDeviceManagerWin32
and GdkWin32Screen objects, and so we can just do away with the global
_gdk_display global variable.
This way, we can also drop the venerable gdkglobals-win32.c source file.
Yay!
Instead, use [Set|Get]WindowLongPtr(), to store and retrieve that
value from the notification window HWND that we are using, as it
is where we are using that value.
Tuck the _win32_device_manager global variable into GdkWin32Display, and
drop the global variables that have to do with GdkDeviceManagerWin32.
Also improve how we query the WinPointer APIs from user32.dll, so that
we are sure that it is done once and only once.
Tuck the GdkWin32Clipdrop that we create in our GdkWin32Display, and
tuck the other associated global variables into GdkWin32ClipDrop and
GdkWin32Drag, as appropriate.
Also, since we are already registering "GDK_WORKER_THREAD_WAKEUP" as our
custom message to look for in our DND/clipboard ops, only register it
once, not twice, as it's not really necessary to do so since
RegisterWindowMessage() returns the same value for the same identifier
that is being used.,
Instead, record the current thread in the GdkDisplay, under a structure
for DND items, which will hold other relevant Windows Clipbord/DND global
variables.
Add a new function in gdkdrag-win32.c to check whether the current
thread is (or is not) equivilant to the thread that is initiated when
the GdkDisplay is initialized (which also returns true if there is no
GdkDisplay that is associated with the GdkDrag in question).
Rename gdkwin32id.c as gdkwin32misc.c.
Fold these items into GdkWin32Display, and also fold gdkproperty-win32.c
and gdkwin32langnoticiation.[c|h] into gdkwin32misc.c and gdkdisplay-win32.h as
appropriate.
This way, we get rid of few more global variables, and these items
should have been initialized (and registered with the system) when we
open a GdkWin32Display anyways.
Use the gdk_win32_surface_parent_class that is given to us by
G_DEFINE_TYPE() instead of using a global variable to store up the
parent class of GdkWin32Surface.
... and print if a format is advertised.
We now use the same style of message and use the term "advertise" for
formats that will be available via GdkDisplay::dmabuf-formats and
"supports" for formats the backend pretends it can handle but don't
want to advertise them.
Instead of only printing the advertised dmabuf formats, print all
supported ones. This is now useful information because we will try to
use them when downloading.
Fixes me looking like I don't know what I'm talking about on IRC when
claiming that llvmpipe can't do dmabufs, because it only supports linear
ones and we didn't print those.
