glxProbeDriver() concatenates __DRI_DRIVER_GET_EXTENSIONS with driver name
to get symbol name for get_extension function. Unfortunately that doesn't
work for drivers that have hyphen in their name, e.g. sun4i-drm --
get_extensions() for these uses underscore instead.
As result dlsym() doesn't find get_extension() function and AIGLX
initialization fails resulting in following message in Xorg.0.log:
(EE) AIGLX error: sun4i-drm does not export required DRI extension
Replace all non-alpha-numeric characters with underscore to fix the issue.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Otherwise X server crashes if GLX is enabled and Composite disabled. For
example the compIsAlternateVisual function will try to lookup CompScreenPtr
using the CompScreenPrivateKey, but that was never initialized if Composite is
disabled.
Fixes: f84e59a4f4. ("glx: Duplicate relevant fbconfigs for compositing visuals")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104993
Signed-off-by: Michal Srb <msrb@suse.com>
Allow switching to another driver build without a full installation.
Glamor already takes LIBGL_DRIVERS_PATH into account, so this change
makes sure that the same driver is used in both parts of the server.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Ben Crocker <bcrocker@redhat.com>
Commit 91c42093b2 ("glx: Duplicate relevant fbconfigs for
compositing visuals") adds many new depth 32 fbconfigs as
composite visuals. On a X-Screen running at depth 24, this
also adds bgra 10-10-10-2 fbconigs, as they also have
config.rgbBits == 32, but these are not displayable on a
depth 24 screen, leading to visually corrupted desktops
under some compositors, e.g., fdo bug 104597 "Compton
weird colors" when running compton with
"compton --backend glx".
Be more conservative for now and only select fbconfigs with
8 bpc red, green, blue components for composite visuals.
Fixes: 91c42093b2 ("glx: Duplicate relevant fbconfigs for
compositing visuals")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104597
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Previously, before GLX_OML_swap_method was fixed, both the X server and
client ignored the swapMethod fbconfig value, which meant that, if the dri
driver thought it exposed more than one swapMethod, it actually just
exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method
and restricting the choice for built-in visuals to a single swap method
that meant we didn't have that many fbconfigs to choose from when pairing
the compositing visual with an fbconfig, resulting in the fbconfig paired
with the compositing visual becoming too restrictive for some applications,
(at least for kwin). This problem would also happen if the dri driver
only exposed a single swap method to begin with.
So, to make sure the compositing visual gets a good enough fbconfig,
duplicate fbconfigs that are suitable for compositing visuals and make
sure these duplicated fbconfigs can be used only by compositing visuals.
For duplicated fbconfigs not paired with a compositing visual, construct
new compositing visuals, making compositing clients able to choose visuals
/ fbconfig more adapted to their needs.
This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING"
GLX visualtype.
Fixes: 4486d199bd ("glx: Fix visual fbconfig matching with respect to
swap method")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102806
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Tested-By: Nick Sarnie <commendsarnex@gmail.com>
Tested-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The swapMethod config member would typically contain an arbitrary value
on older dri drivers. Fix this so that if we detect an illegal value,
return GLX_SWAP_UNDEFINED_OML.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Not even a single DRI2/DRISW driver in mesa ever used this. Appears to be a
dri1 artefact copy/pasted in the dri2/drisw codebase.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
>From the GLX spec:
"GLX_X_RENDERABLE is a boolean indicating whether X can be used to
render into a drawable created with the GLXFBConfig. This attribute
is True if the GLXFBConfig supports GLX windows and/or pixmaps."
Every backend was setting this to true unconditionally, and then the
core ignored that value and sent true unconditionally on its own. This
is broken for ARB_fbconfig_float and EXT_fbconfig_packed_float, which
only apply to pbuffers, which are not renderable from non-GLX APIs.
Instead compute GLX_X_RENDERABLE from the supported drawable types. The
dri backends were getting _that_ wrong too, so fix that as well.
This is not a functional change, as there are no mesa drivers that claim
to support __DRI_ATTRIB_{UNSIGNED_,}FLOAT_BIT yet.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The visualSelectGroup wasn't getting set (since our DRI drivers don't
use it), and and since it's the top priority in the sort order, you
got random sorting of your visuals unless malloc really returned you
new memory. This manifested as Xephyr -glamor rendering to a
multisampled window on my system, which as you might guess was
slightly lower performance than expected.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Those defines are so you can compile-time check "do I have a
dri_interface.h that defines this new field of the struct?" You don't
want the server to claim it implements the new struct just because you
installed a new copy of Mesa.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We're Y-inverted from GL's coordinates, so this is correct. gnome-shell
doesn't seem to check this - somewhat reasonable since the only server
that answered the other way around was Xglx - but kwin does, and
upside-down hilarity ensues.
Tested-by: maelcum on #xorg-devel
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Replaces old use of floatMode attribute with new, extended range of
values in __DRI_ATTRIB_RENDER_TYPE. Also adds new conditions, where the
float modes support requires it. Enables support for not only float
configs, but packed float configs as well.
v2 (idr): Whitespace and formatting fixes. Refactor render type
vs. pbuffer checking to a separate function that includes a quote from
the spec. Re-write commit message. Fix compiler warnings:
glxdricommon.c: In function 'glxConvertConfigs':
glxdricommon.c:212:35: warning: pointer targets in passing argument 3 of 'core->getConfigAttrib' differ in signedness [-Wpointer-sign]
glxdricommon.c:212:35: note: expected 'unsigned int *' but argument is of type 'int *'
glxdricommon.c:230:35: warning: pointer targets in passing argument 3 of 'core->getConfigAttrib' differ in signedness [-Wpointer-sign]
glxdricommon.c:230:35: note: expected 'unsigned int *' but argument is of type 'int *'
Signed-off-by: Daniel Czarnowski <daniel.czarnowski@intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This is going to be exposed (and not the old entrypoint) for some DRI
drivers once the megadrivers series lands, and the plan is to
eventually transition all drivers to that. Hopefully this is
unobtrusive enough to merge to stable X servers so that they can be
compatible with new Mesa versions.
v2: typo fix in the comment
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Changes to correctly initialize the sRGB capability attribute and
transfer it between XServer and the client. Modifications include
extension string, transferring visual config attribs and fbconfig
attribs. Also, attribute is initialized in the modules which do not
really use it (xquartz and xwin).
This version advertises both ARB and EXT strings, and initializes
the capability to default value of FALSE. It has corrected required
GLX version and does not influence swrast. The sRGB capable attribute
is attached only to those configs which do have this capability.
Both ARB and EXT versions share the same GLX extension enabling bit.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Does what it says on the box, replacing those from Xi/ and glx/.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
DRI, DRI2 and swrast all had near-identical driver probing logic.
Pull it into glxdricommon.
[ajax: warning fix]
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
They've been implemented for a while, but we never advertised them. All we
need to do is set the GLX_PBUFFER_BIT in the drawable type fbconfig
field when we're using DRI2.
https://bugs.freedesktop.org/show_bug.cgi?id=26581
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
