Currently, xorgGlxMakeCurrent() would set the context tag only for
indirect GLX contexts.
However, several other places expect to find a context for the tag or
they would raise a GLXBadContextTag error, such as WaitGL() or WaitX().
Set the context tag for direct contexts as well, to avoid raising an
error and possibly killing the client and set currentClient.
Thanks to Erik Kurzinger <ekurzinger@nvidia.com> for spotting the issue.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit c468d34c72)
(cherry picked from commit aad61e8e03)
If a GLXMakeCurrent request specifies an X window as its drawable,
__glXGetDrawable will implicitly create a GLXWindow for it. However,
the client may have already explicitly created a GLXWindow for that X
window. If that happens, two __glXDrawableRes resources will be added
to the window.
If the explicitly-created GLXWindow is later destroyed by the client,
DrawableGone will call FreeResourceByType on the X window, but this
will actually free the resource for the implicitly-created GLXWindow,
since that one would be at the head of the list.
Then if the X window is destroyed after that, the resource for the
explicitly-created GLXWindow will be freed. But that GLXWindow was
already destroyed above. This crashes the server when it tries to call
the destroyed GLXWindow's destructor. It also means the
implicitly-created GLXWindow would have been leaked since the
FreeResourceByType call mentioned above skips calling the destructor.
To fix this, if __glXGetDrawable is given an X window, it should check
if there is already a GLXWindow associated with it, and only create an
implicit one if there is not.
Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit b7a85e44da)
GCC warned about it:
../../../glx/indirect_dispatch_swap.c:85:1: warning: ‘bswap_CARD64’ defined but not used [-Wunused-function]
85 | bswap_CARD64(const void *src)
| ^~~~~~~~~~~~
Querying the GLX_RENDER_TYPE of a GLX context via glXQueryContext will
currently return the render type of the context's FB config, which is
a bitmask of GLX_RGBA_BIT / GLX_COLOR_INDEX_BIT / ... values. However,
this query should really return the render type that was specified
when creating the context, which is one of GLX_RGBA_TYPE /
GLX_COLOR_INDEX_TYPE / .... To enable this, save the render type when
creating a new context (defaulting to GLX_RGBA_TYPE if unspecified),
and then include this value in the context attributes sent to clients.
With autoconf, hashtable support is built along with Xres support.
Yet, glvnd also use it, so when disabling Xres from configure, the
build will fail at link time because hashtable functions are not
available.
Untie the build of hashtable from Xres support, just like meson build
does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1091
client->errorValue is already set in validGlxFBConfig. Set it in
__glXDisp_CreateContextAttribsARB for consistency.
Signed-off-by: Peter Harris <pharris@opentext.com>
Trivial extension to let the client query whether this is a window
pixmap or pbuffer. Mostly for Mesa's convenience when setting up
drawable state, but plausibly useful for apps and middleware as well.
Upstream OpenGL Registry merge request:
https://github.com/KhronosGroup/OpenGL-Registry/pull/425
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
In file included from ../glx/glxdri2.c:35:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
In file included from ../glx/glxdriswrast.c:39:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
The GLX_ARB_create_context path (with which this should all get unified,
someday, sigh) already enforces this, but the classic path does not.
It's effectively assumed by the implementation anyway, so let's enforce
it rather than do crashy things.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
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>
It's true that the value would always be -1, if it's not zero, but it's
usually zero is the problem. As a result we return failure from
otherwise successful indirect GLX paths, which isn't very nice of us.
This reverts commit 7d33ab0f8c.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/211
This ensures that any prep work for the drawable we're about to read
from is already done before we call down to GetImage. This should be no
functional change as most of the callers with a non-trivial
SourceValidate are already wrapping GetImage and doing the equivalent
thing, but we'll be simplifying that shortly.
More importantly this ensures that if any of that prep work would
generate events - like automatic compositing flushing rendering to a
parent pixmap which then triggers damage - then it happens entirely
before we start writing the GetImage reply header.
Note that we do not do the same for GetSpans, but that's okay. The only
way to get to GetSpans is through miCopyArea or miCopyPlane - where the
callers must already call SourceValidate - or miGetImage - which this
commit now protects with SourceValidate.
Fixes: xorg/xserver#902
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When using mesa with libglvnd support, mesa will no longer install the
gl, glx, egl pkg-config files but instead let libglvnd provide them.
libglvnd maintainers decided to change the versioning as it was
mesa-specific previously. Now the libraries have versions of the API
they expose[1].
This causes problems when building the X server:
checking for glproto >= 1.4.17 gl >= 9.2.0... no
configure: error: Package requirements (glproto >= 1.4.17 gl >= 9.2.0) were not met:
Requested 'gl >= 9.2.0' but version of gl is 1.2
Lower the version requirement to 1.2 to allow building against libglvnd
provided libraries
[1] 0dfaea2bcb
GLX_EXT_import_context allows multiple clients to share the same
indirect context. If you can't create an indirect context, you're
certainly not going to be able to share one. Hide the extension from the
server string if we've disabled indirect contexts.
This turns piglit's tests from fail to skip when indirect contexts are
disabled. Since GLX_EXT_import_context has been supported in
xfree86-derived servers since day 1 (it was included in the initial GLX
code drop from SGI), this is now also a hint to the client that indirect
contexts are unlikely to work at all.
Reviewed-by: Michel Dänzer <michel@daenzer.net>
vnd has already verified that the context tag is valid before this gets
called, and we only set the context tag private data to non-null for
indirect clients. Mesa happens to be buggy and doesn't send MakeCurrent
requests nearly as much as it should for direct contexts, but if you fix
that, then unbinding a direct context would fail here with
GLXBadContextTag.
Sadly Mesa will still need to carry a workaround here for broken
servers, but we should still fix the server.
Commit 56c0a71fdd incremented the
GLXSERVER_VENDOR_ABI_MINOR_VERSION define, but this define was not actually
being used to set glxServer.minorVersion.
Update the initializer for glxServer to use the correct version numbers.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Add a new function, GlxServerExports::setClientScreenVendor, which will change
the vendor that handles GLX requests for a screen, but only for requests from
a specific client.
v2: Increment the GLXVND minor version number.
v3: Note the GLXVND version requirement for setClientScreenVendor.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When GlxGetXIDMap looks up an unknown XID, it will now look up a vendor based
on the screen number for the XID and the client that sent the current request.
In GlxGetXIDMap, if the XID is for a regular X window, then it won't be in the
(XID -> vendor) mapping, so we have to look up a vendor by screen number.
With this change, GlxGetXIDMap will use the (screen -> vendor) map for
whichever client sent the current request, instead of using the global
(screen -> vendor) map.
Since GlxGetXIDMap doesn't take a ClientPtr argument, GlxDispatchRequest will
store the client for the current request in a global variable. That way, the
ABI for GLXVND doesn't need to change.
v2: Fix an error check in GlxDispatchRequest.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Each client now has its own (screen, vendor) mapping.
Currently, it's just a copy of the global mapping, but later changes will allow
it to change.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
glxc->drawPriv will be NULL if the context is direct, or if it is
current but without a bound drawable. Mesa's libGL won't normally emit
protocol for direct contexts for these calls, but a malign client could
still crash the server.
None of this was getting compiled because we hadn't defined the macro
(and aren't getting them from <GL/glxext.h> because reasons). Fix that.
Fixes: xorg/xserver#684
Commit 99f0365b "Add a command line argument for disabling indirect GLX"
added a test to check if indirect context are enabled in
`DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't
use `DoCreateContext()` and doesn't check if indirect context is
enabled.
As a result, clients can still manage to create indirect contexts using
`glXCreateContextAttribsARB()` even if indirect contexts are disabled,
which can possibly crash Xservers such as Xwayland or Xephyr when the
context is destroyed.
To avoid the issue, check for `enableIndirectGLX` in
`__glXDisp_CreateContextAttribsARB()` as well.
Fixes: 99f0365b "Add a command line argument for disabling indirect GLX"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The keySize parameter of the hashing/comparison functions was
incorrectly specified to be sizeof(void*), even though the keys of
this hashtable are CARD32.
Fixes address sanitizer failure on 64-bit builds.
Reviewed-by: Adam Jackson <ajax@redhat.com>
fb is happy to do TrueColor to 8bpp drawables, but mesa is not. Depth 12
is the biggest pseudocolor anyone ever really did, and 15 is the least
truecolor.
Without this Xvfb at depth 8 would "have" GLX, but no vendors
would actually back any of the screens. libGL will attempt to call
GLXQueryServerString to figure out the GLX version, and vnd will throw
an error because there's no vendor to dispatch that to, and then clients
crash.
Signed-off-by: Adam Jackson <ajax@redhat.com>
No functional changes, just fixing a tabs vs. space error I noticed
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.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>
The GLVND layer will destroy all of the vendor handles at the end of each
server generation, but the GLX module then tries to re-use the same (now-freed)
handle in xorgGlxServerInit at the start of the next generation.
In xorgGlxCloseExtension, explicitly destroy the vendor handle and set it to
NULL so that the next call to xorgGlxServerInit will recreate it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When a callback list is initialized using CreateCallbackList via AddCallback,
the list gets added to the listsToCleanup array, and as a result the list gets
deleted at the end of the server generation.
But, vendor libraries add themselves to that callback list only once, not once
per generation, so if you delete the list, then no vendor will register itself
on the next generation, and GLX breaks.
Instead, use a static CallbackListRec for the extensionInitCallback list. That
way, it doesn't get added to listsToCleanup, and doesn't get deleted during a
reset.
Reviewed-by: Adam Jackson <ajax@redhat.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>
These guards were dropped by the commit below, but it turns out they're
needed. Fixes crash on VT switch.
Fixes: d8ec33fe05 ("glx: Use vnd layer for dispatch (v4)")
Bugzilla: https://bugs.freedesktop.org/105233
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
We would throw BadValue here for the GLX_SCREEN attribute. The upper
dispatch layer already checks this, we can ignore it here.
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is mostly for the client library's convenience, if this extension
is listed then it can know the attribute won't be rejected. Note that we
don't honor this attribute for indirect contexts. That's fine, we don't
want to introduce undefined behavior into a potentially privileged
process.
v2: Remember to ignore the attribute (Eric Anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Set the major/minor version it's currently implemented, not the one
provided by the GLXSERVER_VENDOR_ABI_{MAJOR,MINOR}_VERSION macros.
Those are identical for now, but can change in the future.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
malloc can return NULL, unlike GetVendorDispatchFunc. The latter
provides DispatchBadRequest.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
/home/ajax/git/xserver/at/../glx/glxdri2.c: In function ‘create_driver_context’:
/home/ajax/git/xserver/at/../glx/glxdri2.c:444:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
const __DRIconfig *driConfig = config ? config->driConfig : NULL;
I don't know why autotools has decided not to be C99 but at least it's
trivial to fix.
Signed-off-by: Adam Jackson <ajax@redhat.com>
There's no reason a multithreaded client shouldn't be allowed to
interleave other requests (for other contexts) with a RenderLarge. Move
the check into __glXForceCurrent, and store the state in the context not
the client.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Olivier Fourdan
Erik Kurzinger
Michel Dänzer
Peter Harris
Adam Jackson
Alan Coopersmith
Jan Beich
Vasily Khoruzhick
Marvin Schmidt
Aaron Plattner
Kyle Brenneman
Jon Turney
Vladimir Panteleev
Lyude Paul
Michal Srb
Thierry Reding
Nicolai Hähnle
Michel Dänzer
Emil Velikov