The fix from commit c468d34c7 - "glx: Set ContextTag for all contexts"
is actually incomplete, it correctly sets the context tag for direct
contexts as well, but would fail to mark the context's currentClient.
As a result, when the context is destroyed, it would be freed
immediately rather than being just scheduled for deletion, even though
it is still current for some client. leading to a use-after-free.
Make sure to also set the context's currentClient for direct contexts as
well, not just indirect ones.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: c468d34c7 - "glx: Set ContextTag for all contexts"
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1186
Reviewed-by: Adam Jackson <ajax@redhat.com>
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.
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>
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>
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.
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>
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>
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.
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.
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>
The big change here is MakeCurrent and context tag tracking. We now
delegate context tags entirely to the vnd layer, and simply store a
pointer to the context state as the tag data. If a context is deleted
while it's current, we allocate a fake ID for the context and move the
context state there, so the tag data still points to a real context. As
a result we can stop trying so hard to detach the client from contexts
at disconnect time and just let resource destruction handle it.
Since vnd handles all the MakeCurrent protocol now, our request handlers
for it can just be return BadImplementation. We also remove a bunch of
LEGAL_NEW_RESOURCE, because now by the time we're called vnd has already
allocated its tracking resource on that XID.
v2: Update to match v2 of the vnd import, and remove more redundant work
like request length checks.
v3: Add/remove the XID map from the vendor private thunk, not the
backend. (Kyle Brenneman)
v4: Fix deletion of ghost contexts (Kyle Brenneman)
Signed-off-by: Adam Jackson <ajax@redhat.com>
This really just wants to be the list of disable booleans and
initialization functions, and nothing else. Stop including the protocol
headers from extinit.h, remove a stray mention of xgl, and move an
XInput declaration to a better place.
v2: A bunch of drivers assume they'll get the DPMS tokens implicitly,
so add it to globals.h.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Only enabled for the DRI backends at the moment. In principle WGL/CGL
could support this - it's sort of implied by GL 3.0 support - but in
practice their implementations back GLX drawables with native drawables
(and not anonymous FBOs), so they would need either a corresponding
window system binding extension or significant implementation work.
v2: Require that the two screen numbers match, per v4 of spec.
Khronos: https://github.com/KhronosGroup/OpenGL-Registry/pull/102
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Any proper (GLX 1.3) drawable will already have a bound config, but if
we're doing the GLX 1.2 thing of making a Window current, we need to
infer the config from the window's Visual.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Just never filled in, oops. Seems to have gone unnoticed because
normally glXQueryContext simply returns the values filled in by the
client library when the context was created. The only path by which you
normally get to a GLXQueryContext request is glXImportContext, and then
only if the context is already indirect.
However, that's a statement about Mesa's libGL (and anything else that
inherited that bit of the SGI SI more or less intact). Nothing prevents
a mischeivous client from issuing that request of a direct context, and
if they did we'd be in trouble because we never bothered to preserve the
associated fbconfig in the context state, so we'd crash looking up
GLX_VISUAL_ID_EXT. So let's fix that too.
v2: Fixed missing preservation of the config in DRI2 (Eric Anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
If the context is direct none of the GL commands were issued by this
process, the server couldn't flush them even if it wanted to.
v2: Fix embarassingly obvious boolean inversion (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Dead code since:
commit 8aacf47e17
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Oct 4 12:58:19 2013 -0400
glx: Remove DRI1 AIGLX (v2)
Signed-off-by: Adam Jackson <ajax@redhat.com>
GLX_ARB_create_context, which we aspire to support, allows making GL 3.0
or newer contexts current with null current drawables. Strictly this
might not be legal for pre-3.0 contexts, but there's no harm in allowing
it anyway.
Signed-off-by: Adam Jackson <ajax@redhat.com>
We already send this for fbconfigs. Mesa happens to implement
glXChooseVisual relative to the fbconfig data, but that might not be
true of NVIDIA's libGL.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If windowsdriproto headers are available, build a Windows-DRI extension,
which supports requests to enable local clients to directly render GL to a
Windows drawable:
- a query to check if WGL is being used on a screen
- a query to map a fbconfigID to a native pixelformatindex
- a query to map a drawable to a native handle
Windows-DRI can only be useful if we are using WGL, so make an note if WGL
is active on a screen.
Make validGlxDrawable() public
Adjust glxWinSetPixelFormat() so it doesn't require a context, just a
screen and config.
That enables factoring out the deferred drawable creation code as
glxWinDeferredCreateDrawable()
Enhance glxWinDeferredCreateDrawable(), so that pixmaps are placed into a
file mapping, so they exist in memory which can be shared with the direct
rendering process.
Currently, this file mapping is accessed by a name generated from the XID.
This will not be unique across multiple server instances. It would perhaps
be better, although more complicated, to use an anonymous file mapping, and
then duplicate the handle for the direct rendering process.
Use glxWinDeferredCreateDrawable() to ensure the native handle exists for
the Windows-DRI query to map a drawable to native handle.
v2:
Various printf format warning fixes
v3:
Fix format warnings on x86
Move some uninteresting windows-dri output to debug log level
v4:
check for windowsdriproto when --enable-windowsdri
use windowsdriproto_CFLAGS
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.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>
This is only meaningful for indirect contexts, and all it does is
(maybe) prevent a flush when switching away from an indirect context.
Indirect contexts aren't worth optimizing for, and Mesa tracks whether
a flush is needed anyway.
Careful readers will note that ReadPixels would reset the flag even
though it doesn't imply a flush!
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
For the dri2 backend, we depend on xfree86 already, so we can walk the
options for the screen looking for a vendor string from xorg.conf. For
the swrast backend we don't have that luxury, so just say mesa. This
extension isn't really meaningful on Windows or OSX yet (since libglvnd
isn't really functional there yet), so on those platforms we don't say
anything and return BadValue for the token from QueryServerString.
v2: Use xnf* allocators when parsing options (Eric and Emil)
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is correct as it is, but only because we know no DRI drivers
implement stereo.
v2: Use new ATTRIB macro
Reviewed-by: James Jones <jajones@nvidia.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
libglvnd would like to use this to map from drawable to screen, so it
can know which driver to dispatch to. Refer to the spec proposal here:
https://lists.freedesktop.org/archives/mesa-dev/2016-March/109543.html
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
No functional change, just a little easier to read and harder to get
wrong.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
AddResource will have called DrawableGone, which takes care of the
destruction.
Reviewed-by: Rémi Cardona <remi@gentoo.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>
This extension allows clients to opt out of the implicit glFlush on
context release, which is quite nice for performance for clients using
multiple contexts. The server doesn't really need to be aware of the
client's decision, at least for direct contexts, but it does need to not
reject the context attribute out of hand.
This patch won't do anything unless built against a Mesa that defines
the __DRI2_FLUSH_CONTROL extension (and a new enough glxext.h, but
that's been there since 10.3 at least).
Reviewed-by: James Jones <jajones@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Some people like to call this on bare Window XIDs and expect reasonable
results. I sure wish they wouldn't, but since they do, if we're given
a window without any glx decoration just fill in as much as we can. This
means you won't actually get an answer for GLX_FBCONFIG_ID and friends,
but there's not much to be done about that, and it matches what NVIDIA's
driver seems to do.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54080
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This adds a dummy implementation for the loseCurrent function in
__GLXContext for direct contexts which just returns GL_TRUE. Without
this then the X server can crash if receives a MakeCurrent message for
a direct context because it will attempt to call loseCurrent when
cleaning up the client in the callback for ClientStateGone.
[ajax: added assumed s-o-b line]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86531
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Neil Roberts <neil@linux.intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
v2: Handle more multiplies in indirect_reqsize.c (Julien Cristau)
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This is a half-measure until we start passing request length into the
varsize function, but it's better than the nothing we had before.
v2: Verify that there's at least a large render header's worth of
dataBytes (Julien Cristau)
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
v2:
Remove can't-happen comparison for cmdlen < 0 (Michal Srb)
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If the size computation routine returns -1 we should just reject the
request outright. Clamping it to zero could give an attacker the
opportunity to also mangle cmdlen in such a way that the subsequent
length check passes, and the request would get executed, thus passing
data we wanted to reject to the renderer.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Michal Srb <msrb@suse.com>
Reviewed-by: Andy Ritger <aritger@nvidia.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This reverts commit 7f5adf73a0.
This seems to miss the whole point of the idExists flag, as it makes the
lifetime of that being true the same as the lifetime of the Context resource.
The previously current context tag is always given in a MakeContextCurrent
request, even if that context tag is no longer valid (for example, the context
has been deleted), so this leads to BadContextTag errors.
See fd.o bug #30089 for the makecurrenttest.c testcase, and some discussion of
previous manifestations of this bug.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Present didn't provide the 'kind' argument to the
present_complete_notify hook that GLX uses to construct
GLX_BufferSwapComplete events, so GLX was reporting events for
PresentCompleteKindMSC notifications, which resulted in duplicate
GLX_BufferSwapComplete events and crashes in clutter.
See the gnome bug: https://bugzilla.gnome.org/show_bug.cgi?id=733282
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The attack surface for indirect GLX is huge, and it's of no use to
most people (if you get an indirect GL context, you're better served
by a immediate X error than actually trying to use an indirect GL
context and finding out that it doesn't support doing anything you
want, slowly). This flag gives you a chance to disable indirect GLX
in environments where you just don't need it.
I put in both the '+' and '-' arguments right now, so that it's easy
to patch the value to change the default policy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We want to make sure that lastGLContext is set correctly during
makeCurrent, because we may have recursive GL context changes in the
DRI2 interfaces due to glamor.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Olivier Fourdan
Erik Kurzinger
Adam Jackson
qarmin
Alan Coopersmith
Emil Velikov
Jon Turney
Julien Cristau
Jeremy Huddleston
Neil Roberts
Peter Hutterer
Keith Packard
Eric Anholt