GLX_EXT_tetxure_from_pixmap operates on a GLXPixmap, which takes a
reference on the backing pixmap; that GLXPixmap might be long-lived, so
we should account for it in ResQueryClientPixmapBytes.
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
When multiple processes are using GL with indirect rendering a race
condition can make drawables refcount never drop to zero.
This situation could happen when there are many X clients using indirect
GLX:
1 - client1: calls glXMakeCurrent
2 - client2: calls glXMakeCurrent
This is the first context switch for this client. So old_context_tag=0
3 - client1: calls glXRender
For the client, its context is already current.
For the server side lastGLContext points to client2's context.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Guilherme Quentel Melo <gqmelo@gmail.com>
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>
No functional change, just rearranging some code to make later commits
more obvious.
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>
Now that the enable bits are in the screen base class we can compute
this in one place, rather than making every backend do it.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
GLX 1.3 implies equivalent functionality, so this is safe to enable
unconditionally, and bindContext always takes both drawable and readable
arguments in any case. Mesa stopped exporting the __DRI_READ_DRAWABLE
extension in 8.0 (when the DRI1 drivers were removed) so this will
restore the extension string.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Not all backend servers implement this. Those that don't happen to not
use __glXInitExtensionEnableBits, but we'd like that to change, so fix
it up before we switch them over.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This extension is direct-only and has no GLX protocol. We don't even
track an enable bit for it, trying to turn it on is pointless.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This existed only to be strdup'd and then immediately freed.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The tokens for this are already defined by GLX_ARB_fbconfig_float, which
we already support, so just add the extension to the list and let the
driver provide those configs if it wants.
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
As of v4 of this extension, any GLES version number may be requested (to
enable GLES3 and later). To comply with this, simply remove the API
version checks and leave it to the DRI driver to validate. This happens
to also enable using GLES1 in direct contexts, so if that's the dire
situation you find yourself in, your client driver at least stands a
chance of working.
v4 also specifies that both extension strings should be advertised for
compatibility with clients written against v1 of the extension spec, so
add the es_profile bit to the extension list and enable it whenever we
would enable es2_profile.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Adam Jackson <ajax@redhat.com>
So copy sub buffer isn't a core extensions it's a driver extension
which means we are using totally the wrong interface to query for it
here, which means bad things happen when you roll out this code,
for instance MESA_copy_sub_buffer stops working.
This is just the hack I'm sticking in Fedora to avoid the regression
for now, but hopefully will inspire us.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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>
This gets you nice things like core contexts when using Xvfb.
Also, no, MESA_copy_sub_buffer is not enabled automatically.
Reviewed-by: James Jones <jajones@nvidia.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This reverts commit d61ae18074.
If the DRI2 provider is disabled, then we don't advertise the correct
GLX extensions to clients, and things like GLES fail.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90442
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
There is no point in setting up the acceleration for indirect GLX if
indirect GLX is itself disabled.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
v2: fixup whitespace
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.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>
We're using compiler compatibility settings which generate warnings
when a variable is declared after the first statement.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
On a system where sizeof(unsigned) != sizeof(intptr_t), the unary
bitwise not operation will result in a mask that clears all high bits
from temp_buf in the expression:
temp_buf = (temp_buf + mask) & ~mask;
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.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>
v2:
Fix single versus vendor-private length checking for ARB_imaging subset
extensions. (Julien Cristau)
v3:
Fix single versus vendor-private length checking for ARB_imaging subset
extensions. (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: Julien Cristau <jcristau@debian.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
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>
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>
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 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:
Fix constants in __glXMap2fReqSize (Michal Srb)
Validate w/h/d for proxy targets too (Keith Packard)
v3:
Fix Map[12]Size to correctly reject order == 0 (Julien Cristau)
Reviewed-by: Keith Packard <keithp@keithp.com>
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>
These are paranoid about integer overflow, and will return -1 if their
operation would overflow a (signed) integer or if either argument is
negative.
Note that RenderLarge requests are sized with a uint32_t so in principle
this could be sketchy there, but dix limits bigreqs to 128M so you
shouldn't ever notice, and honestly if you're sending more than 2G of
rendering commands you're already doing something very wrong.
v2: Use INT_MAX for consistency with the rest of the server (jcristau)
v3: Reject negative arguments (anholt)
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>
Without this we'd reject the request with BadLength. Note that some old
versions of Mesa had a bug in the same place, and would _send_ zero
bytes of image data; these will now be rejected, correctly.
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>
If the computed reply size is negative, something went wrong, treat it
as an error.
v2: Be more careful about size_t being unsigned (Matthieu Herrb)
v3: SIZE_MAX not SIZE_T_MAX (Alan Coopersmith)
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>
Before this we'd just clamp the image size to 0, which was just
hideously stupid; if the parameters were such that they'd overflow an
integer, you'd allocate a small buffer, then pass huge values into (say)
ReadPixels, and now you're scribbling over arbitrary server memory.
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>
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>
With the previous patches applied, we now have crash due to use-after-free when
a client exits without deleting all it's GL contexts
On client exit, CloseDownClient first calls glxClientCallback() with
ClientStateGone, which calls __glXFreeContext() directly.
Subsequently CloseDownClient() frees all the clients resources, which leads to
ContextGone() being called for a context resource where the context has already
been freed.
Fix this by modifiying glxClientCallback() to free the context resource.
Also make __glXFreeContext() static, as calling it directly leads to this
problem, instead the context resource should be released.
With the previous patches applied, this can be demonstrated with e.g. glxinfo,
which doesn't delete it's context before exit.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Some sequences of glean tests fail with GLXBadCurrentWindow when using indirect
rendering, e.g. glean -t 'fpexceptions getString'.
Flush a context which is being made non-current due to the drawable on which is
it is current going away. Waiting until another context is made current is too
late, as the drawable no longer exists.
v2: Rewrite for direct GL dispatch
v3: Inline FlushContext(), doesn't need to be a separate function
e.g. LIBGL_ALWAYS_INDIRECT=1 ./glean -r results -o --quick -t "fpexceptions
getString" fails with a BadContextTag error.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.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>
