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>
/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>
glxinfo already exists, use it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
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>
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>
The trailing \n are just wrong here, __glXEnableExtension wants a string
without them.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.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>
Those are xlib spellings, we say TRUE/FALSE pretty consistently
elsewhere in the server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This isn't an error if the screen isn't accelerated in the first place.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
They're not needed, and they won't be present on win32.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.l.veikov@gmail.com>
>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>
noClientException is now never filled in with a meaningful value, it's
always -1. The sole caller of this function disregards the error value
in any case.
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>
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>
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 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>
ctx_attribs had room for 3 pairs of attributes, but if both flags & reset
attributes were being returned it was storing 4 pairs in the array.
Found by Coverity #53442: Out-of-bounds write
This could cause an immediate crash or incorrect computations.
In create_driver_context: Out-of-bounds write to a buffer (CWE-119)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
By changing the context, it may also invalidate the DRI2 buffer
information, so we need to get that again.
Fixes crashes due to use-after-free with LIBGL_ALWAYS_INDIRECT=1
glxgears and piglit.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
These functions are called from the GL driver, in some series of GL
calls by GLX. If some server component (like glamor CreatePixmap for
GetBuffers()) changes the GL context on us, we need to set it back or
the later GL calls will land in the glamor context instead of the GLX
context.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
I needed to add some code to each one, so it's a good time to make a
helper func.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Thanks to configure.ac's check, we know that we have a new enough
dri_interface.h that we don't need to conditionalize all this code.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.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>
This allows GL to support the GLX_INTEL_swap_event extension.
v2: Return GLX_BLIT_COMPLETE_INTEL for unknown swap types
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
In a similar spirit to
commit d75e8146c4
Author: Keith Packard <keithp@keithp.com>
Date: Mon Jul 12 16:01:34 2010 -0700
Unwrap/rewrap EnterVT/LeaveVT completely, Fixes 28998
we need to unwrap our pScrn->EnterVT/LeaveVT hooks around server
regeneration or else we cause an infinite recursion on the next VT
switch afterwards.
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1235516
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We now expect to be linked against something that provides the GL API,
instead of manually grubbing about in the DRI driver's dispatch table.
Since the GLX we expose calls GL functions that are meant to be looked
up dynamically, also add a way to thunk through to GetProcAddress.
This includes a refresh of the generated sources, which requires a
correspondingly new Mesa.
The GetProcAddress stubs are at the moment merely enough to make this
link against Mesa 9.2, but should really be provided for everything not
in the OpenGL 1.2 ABI.
v2: Explicitly hide the GetProcAddress stubs so we can't conflict with
libGL symbols; fix leading tab/space issues [anholt]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
v2 (idr): Maintain sort order of extension list. Fixed rebase error
(comment header for initializeExtensions was in front of
__glXDRIinvalidateBuffers). Re-write commit message.
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>
The DRI2 code is now built-in to the server, even for Xorg. The only
thing this could protect against is trying to run a libglx built with
DRI2 support against an Xorg built without it, which is firmly in
"doctor it hurts when I do this" territory.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Backtrace logging etc. is already sigsafe, but the actual FatalError message
in response is not yet, leading to amusing logs like this:
(EE) Segmentation fault at address 0x0
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:499 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in
signal context.
Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or
ErrorFSigSafe().
The offending log format message is:
Fatal server error:
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reported with other leaks found by cppcheck in bugzilla #50281https://bugs.freedesktop.org/show_bug.cgi?id=50281
V2: goto existing error handler, instead of replicating more of it here
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Swap events depent on the implementation of ScheduleSwap. By
unconditionally enabling GLX_INTEL_swap_event we're breaking
the system with drivers that don't support it because the apps
are forever stuck waiting for an event that will never be
delivered. So lets enable the extension only if the hooks it
depends on are actually there.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.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>
Running glxinfo under indirect rendering would randomly fail against the
intel driver, as it would create a context with no attribs, and then the
api value would be passed to the driver uninitialised.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
