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>
Save any value of the kernel non-desktop property in the xf86Output
structure to avoid non-desktop outputs in the default configuration.
[Also bump randrproto requirement to a version that defines
RR_PROPERTY_NON_DESKTOP - ajax]
Signed-off-by: Keith Packard <keithp@keithp.com>
(Ported from xserver commit b91c787c4cd2d20685db69426c539938c556128a)
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
xorg-server.h defines _XSERVER64 which is used in X.h to choose the
correct definition of XID
this prevents a failure in the present.h configure test that disables
DRI3 on X.Org 1.20
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
xserver 1.13.0 was released on September 6th, 2012, almost 5 years ago.
This allows cleaning up a bunch of backwards compatibility code.
(Ported from radeon commit 5cdd334b3402c2431deb3a87a8d04ef590da53ee)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Despite all the careful planning of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.
Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. The kernel may be able to get the
link to work by dropping to using a lower link bpp (with the same
display bpp). However, the modeset may fail if the kernel has pruned
the mode, so to make users aware of this problem a warning is outputed
in the logs to warn about having a potentially-black display.
This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.
(Ported from xserver commit bcee1b76aa0db8525b491485e90b8740763d7de6)
[ Michel: Bump libdrm dependency to >= 2.4.78 for
DRM_MODE_LINK_STATUS_BAD ]
(Ported from radeon commit 0472a605e0ec8fec1892bbc3a84698b7ef9c5296)
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* Point to the amd-gfx mailing list
* Specify the component in all bugzilla URLs
* Use https:// for all HTML URLs
(Ported from radeon commit d80d01a73c2eaba2e3649b7bc0a3541b3ff782f6)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
