Currently dmabuf_dep is found when the following conditions are met:
- linux/dma-buf.h is present;
- libdrm is found.
This is because Linux dmabuf support requires drm_fourcc.h which is part
of libdrm.
However, dmabuf_dep is used for two purposes:
- define HAVE_DMABUF to state dmabuf support;
- ensure the presence of drm_fourcc.h for gdk and for the
media-gstreamer module.
Decouple this, unconditionally check for libdrm and require it on
Linux. Then, use libdrm_dep only to state the drm_fourcc.h presence.
Given that now we unconditionally require libdrm on Linux, HAVE_DMABUF
depends only on the linux/dma-buf.h presence.
We can derive whether we are build a developement snapshot or
a stable version from the minor version number. So do that.
This way, we'll get the devel profile selected in the nightly
SDK, which will make the commit sha appear in the inspector,
which is useful to determine what nightly users are testing.
We want to use the same header in the inspector, so move it to
the toplevel. And since it is no longer for demos only, rename
it to profile_conf.h, and also rename the build option back
to profile.
It's still possible to disable via -Dvulkan=disabled
We force-disable it on Mac OS.
I don't know how to best handle it on Windows. Technically we don't need
it, because the Vulkan stuff we want is about dmabufs, but I have no
idea how to convince the build system to toggle the default to
"disabled" on Windows, so it has to stay enabled for now.
Some dmabuf formats were added in Vulkan 1.3.
Note that this does not require the Vulkan drivers to be version 1.3 -
it just means compilation against libvulkan 1.3
We really always want to force-include msvc_recommended_pragmas.h to check for
things at compile time so that we can avoid stuff like missing includes or
attempting to return a value in a function that is supposed to have a
void-return-type.
The current problem is that, as indicated in the Visual Studio CI job, that we
couldn't locate msvc_recommended_pragmas.h during the build if GLib is built
as a subproject, and/or when msvc_recommended_pragmas.h is not in the paths
indicated by %INCLUDE%, meaning that the aforementioned issues would not be
caught by CI, which will then break builds on Visual Studio for people when
msvc_recommended_pragmas.h is found during their builds.
It would also be nice to be quiet from the warnings that we can really
disregard anyways.
So, add a copy of msvc_recommended_pragmas.h from GLib and update the build
files to look for it in build-aux/msvc, so that it can always be used during
the build, especially by the CI.
Add an implementation of GdkDmabufTexture.
For now, this implementation is rather minimal,
since we need a roundtrip through GL to convert
most nottrivial formats.
We need to inist on the nonuniform access beuing available and that
requires Vulkan 1.2.
Also simplifies the descriptor indexing stuff, because that's all part
of Vulkan 1.2, too.
That's a gcc warning (clang has the equivalent -Winitializer-overrides,
but that one is included in -Wall) that complains about things like:
VkOffset3D offset = { .x = pt.x, .x = pt.y, .y = 0 };
So you don't have to spend a few hours trying to understand what's going
on before realizing your copy/paste skills are substandard.
While working on deprecation cleanups, I noticed
that removing GDK_DEPRECATED_IN... from headers
does not have the effect of making the symbols
disappear, since we were forgetting to set the
default visibility to hidden.
This is implemented using a new xdg_toplevel `suspended` state, and is
meant for allowing applications to know when they can stop doing
unnecessary work and thus save power.
In the other backends, the `suspended` state is set at the same time as
`minimized` as it's the closest there is to traditional windowing
systems.
The objcopy+ld approach to fast resource building
relies on behavior that is specific to the binutils
linker, and does not work with the llvm one.
Therefore, check for ld.bfd. We still fall back
to trying with just ld, since I'm not 100% sure
if binutils unconditionally installs ld.bfd.
Fixes: #5672
We now need glib-2.76.0 or later, which removes our needs for the workarounds
that we need to build the media backends against GLib-2.74.x or earlier, so
clean up things a bit.
We are now using APIs that were introduced in 2.75.x, so let's use glib-2.76.0
here for our glib subproject.
Update the build and gobject-introspection items accordingly
