It's always present - and if it wasn't, the build would also fail
with a clear message.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several extensions like randr and render are always built-in in the
Xserver, no need for having them optional here in any way.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's breaking with Xservers SDK's functions and not needed at all,
since the Xserver SDK already providing platform independent
functions for this. (actually we only need bswap_32() anyways)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Reverts commits 6e65547 and 479df8e.
These commits caused the build to fail on DragonFlyBSD.
mesa-libs 21.3.9 is not by any means ancient, it is only 3 years old and
it is still receiving critical bug fixes, and most importantly it is
still being used on DragonFlyBSD, also these are relatively small and
harmless checks.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This header is always present in xfree86 SDK for aeons now and already
manadatory for this driver, so there's no need for extra check whose
result isn't used anyways.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This symbol is always present for over a decade ago, so no need
to check for it. And so we also don't need any support for old
external libglamor anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always present, no matter whether DRI3 is actually enabled.
No need to care about ancient - pre-DRI3 - Xserver versions.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's present since at least mesa 22.3. No need to care about ancient
mesa versions anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's present since at least mesa 22.3. No need to care about ancient
mesa versions anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is always present since about a decade ago, so no need to
check for it and having a fallback.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is always present for about a decade now, so no need
to check for it (and having a fallback) anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header is always present, no matter whether present extension
actually enabled. Thus no need to explicitly check for it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function is present in the Xserver for way over a decade, so no
need to carry around our own copy anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function has been removed over a decade ago - no need to support
such ancient Xserver versions anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always present, no matter whether MIT sync fencing is actually
enabled in the Xserver (we're checking that at rnutime).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Back a decade ago, somebody obviously idn't know how to check for xserver
version and abused a quite unrelated exported symbol instead. Since that
symbol isn't exported anymore (because no driver was using it), this black
magic now fails.
We're not trying to support more than a decade old Xservers, so there's
no point in this check at all, just drop it.
Fixes: e5dfb6c266
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The module directory has changed to a per ABI folder in the xlibre-xserver.
Now the default value of `xorg-module-dir` will be detected from the `moduledir` variable in xorg-server.pc.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This GBM flag is useful as it allows the driver to be aware
of the intended use of the buffer and act accordingly (typically
disable DCC to avoid artifacts from out of sync DCC).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
[why]
On RHEL9+, xorg-server.pc shows that the Xorg no longer depends on dri,
and dri.pc provides "/opt/amdgpu/include" path for pkg-config, this
cause pkg-config no longer output "-I/opt/amdgpu/include", consequently
the configure can't find gbm.h and HAVE_GBM_BO_USE_LINEAR is not
declared, that cause the corruption.
[how]
Since the gbm.pc also provides the "/opt/amdgpu/include" path, in module
dependence checking, GBM_CFLAGS get this path, so just explicitly add
GBM_CFLAGS into CPPFLAGS can fix this issue.
Signed-off-by: tiancyin <tianci.yin@amd.com>
Older versions of autoconf only supported the former.
(Cherry picked from radeon commit cba8fe4d64819aaa8ba516aa68dbe6d2aa153046)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
It's a bit silly to require current randrproto just for this definition,
which can't really change anyway.
Suggested-by: Qiang Yu <qiang.yu@amd.com>
Reviewed-by: Qiang Yu <Qiang.Yu@amd.com>
