This code would work for GLXWindows but not for bare Windows, which I
guess you could argue is a server bug but which we can fix on the client
side with a little effort. We change __glXGetDrawableAttribute to
additionally return false if we failed to find the requested attribute
(which is safe, all the other callers discard the return value). Then
when inferring the fbconfig, if the attribute wasn't found, we ask for
the window attributes to find the visual ID and use that to find the
fbconfig.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10381>
The initialization we're doing for it in __glXExtensionsCtr is trivial,
and this is only to make glGetString(GL_EXTENSIONS) work in indirect
contexts anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
These are rare enough to not be worth tracking separately. Especially
since after this change all the known_gl_extensions have N for both
direct_support and direct_only (unsurprising, since that's only used to
compute usable indirect extensions).
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
... at least as far as libGL is concerned, because they'd work just fine
if you tried. The only thing the ATI extension seems to add (I can't
find an official spec, this is inferred from the registry XML) is
selecting the GLX_RENDER_TYPE, which we don't validate before putting on
the wire. The only thing the NV extension adds is an additional fbconfig
attribute, and that only known by glXGetFBConfigAttrib; our
implementation of that just reads the value the server sends, if any,
and doesn't try to filter out unknown attributes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
The "left here but disabled" comment dates to 2004! The idea here is to
add extensions implied by a particular GL version to the GL extension
string, but nothing useful is accomplished by doing so, and this is all
only used in the case of indirect rendering anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10223>
Somewhat terrifyingly, we never sent this for direct contexts, which
means the server never knew the context/drawable bindings. To handle
this sanely, pull the request code up out of the indirect backend, and
rewrite the context switch path to call it as appropriate. This
attempts to preserve the existing behavior of not calling unbind() on
the context if its refcount would not drop to zero.
Of course, you can't just do this indiscriminately, because this is GLX
and extant X servers have bugs and everything is terrible. To wit:
- For 1.20.x prior to 1.20.6, you can bind a direct context once, but
the second time you try to modify the context's binding you will get
GLXBadContextTag. This includes unbinding the context. And "deleting"
the context will leak memory, because it will still appear to be
current.
- For 1.19 and earlier, glXMakeCurrent(dpy, None, ctx) should be legal
for GL 3.0+ contexts, but the server will throw BadMatch.
To guard against this, we only send the request for indirect contexts
unless the server is known good, and only mention one context at a time
in such a request; if switching between contexts, we first unbind the
old, and then bind the new. Note that the second VendorRelease() version
is to catch XFree86 4.x and Xorg [67].x, which almost certainly have the
above bugs. Other servers might report different version numbers here,
but we can't do direct rendering against them, so this should be safe.
Fixes: mesa/mesa#4418
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
We've never read any of this out. The transparency stuff we've never
implemented and the shift/mask stuff doesn't vary independently enough
to need to match on.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
Move the macros defining the expected number of attributes into the same
file as their consumer, remove a pointless maximum, and allocate more
space for attribs on the stack to avoid malloc in the common case.
glxext.c knows about 46 config attribs, 46 - 18 = 28, round up to 32 to
future proof a bit.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9992>
Again, NVIDIA supports this on every fbconfig, Mesa alternates it on and
off for some reason but only on some drivers, and in particular llvmpipe
doesn't try to create sRGB-ful fbconfigs. Nerf it out of the fbconfig.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
Mesa marks accumful fbconfigs as slow (for no especially good reason,
it's only accum operations that aren't accelerated, and we could fix
that). NVIDIA doesn't. All that mismatching on this attribute can do is
prevent a config from working exactly as well as it possibly can.
Trust the server's opinion here (but warn if you ask for warnings).
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
For hardware drivers we've never set this to anything interesting so
there's no benefit to validating it. For drisw we're at the mercy of
whatever the X server sent to us anyway, and it's not like any server is
going to vary two fbconfigs by _just_ these values.
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1648>
One, only applegl needs this. Two, this isn't a function of the context
in any way so it doesn't belong in the context vtable. Just special-case
applegl for now, we can revisit applegl's dispatch later.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9690>
The client-side implementation of this operates entirely in terms of the
GL and X client APIs. There's nothing DRI-specific about it, evidenced
by apple and windows using it unchanged. Save a little code size by
handling the direct/indirect difference directly.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9690>
When mesa gets a DRI2 1.1 connection (as experienced with
vmwware DDX) we don't get a pointer for this.
Don't explode just keep going.
Fixes: 60ebeb4608 ("glx: Implement GLX_EXT_swap_control for DRI2 and DRI3")
Reviewed-by: Adam Jackson <ajaX@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9184>
Starting with GL 3.0 it's legal to have no drawable bound to the current
context. GLX_SGI_video_sync doesn't take a drawable for an argument so
it implicitly operates on... something. NVIDIA's driver throws
GLX_BAD_CONTEXT for GetVideoSync, but WaitVideoSync seems to actually
wait for the next MSC on the context's screen. We could work around this
by internally creating/destroying a GLXWindow for the root window, but
for Xwayland there's not necessarily a good answer it can return.
Just throw GLX_BAD_CONTEXT for both.
Fixes: mesa/mesa#1207
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8334>
When using glvnd, this function needs to be exposed through
getDispatchAddress or libglvnd will not find it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Fixes: 60ebeb4608 "glx: Implement GLX_EXT_swap_control for DRI2 and DRI3"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8621>
It's a little unclear from the GLX_ARB_create_context spec whether the
list of supported extensions means what the client supports at all, or
what it knows an indirect GLX encoding for. You'd think it could only
really matter for indirect, since the only way the server would know
about GL commands (as opposed to GLX commands) is if the context was
indirect. And indeed for Xorg's GLX it doesn't matter, because it
doesn't check this, assuming that anything a direct client says works
works, and clamping the GL version based on the protocol it has code
for.
But if you're NVIDIA, apparently, you check this even for direct
contexts. And since drisw creates a nominally "direct" context, this
means llvmpipe and friends get clamped to 3.0 for desktop GL (since
that's as far as the protocol is defined) and can't do GLES at all.
So, whatever, just go ahead and claim to support everything. The wire
representation of the supported versions is strange (see comments in the
code) but it matches what NVIDIA does.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7369>
This is Sort Of handled by nerfing GL_VERSION in __indirect_glGetString,
but that doesn't cover GLES contexts which we also don't have any
indirect support for. Xorg's GLX would reject this for us since it has
the same limitation, but NVIDIA's GLX seems to interpret a request for
ES 2.0 as desktop, despite having the ES2 profile bit set, leading to a
very confusing GL_VERSION string and probably not the ES2-compatible
context you were hoping for.
Since we may now return NULL from indirect_create_context_attribs for
reasons other than malloc failure, we need to reasonably handle the case
where gc == NULL by the time we get to the XCB call. We rely on the
server to generate correct return values in this case, but if it
succeeds despite our client-side failure we just throw GLXBadFBConfig
(chosen to keep piglit/glx-create-context-core-profile happy, since
nothing else seems to hit it).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7369>
When the server doesn't support indirect contexts it will generate a
BadValue error, since the CreateContext request's isDirect field will
have specified an unsupported value of False. We attempt to verify that
context creation succeeded by asking whether the context's XID is direct
or not after we create it. Due to the details of XCB error handling, if
the context wasn't successfully created, the GLXBadContext error from
the GLXIsDirect request will get raised first, hiding the BadValue from
the application.
To fix this, we change the behavior of __glXIsDirect based on the
`error` outparameter. If it is NULL we still raise the error generated
from the GLXIsDirect request, but if it is non-NULL we now just inform
the caller that the request failed and silently eat the error. By doing
this the BadValue (or whatever else) from the CreateContext request will
bubble up to the application as expected.
This is admittedly a bit subtle but it's the simplest way to get to the
fix here. A better solution would be to convert all of CreateContext to
XCB, but XCB doesn't have protocol for GLX_SGIX_fbconfig yet so we'd
lose glXCreateContextWithConfigSGIX.
Fixes: mesa/mesa#3907
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7859>
The GLXIsDirect request will throw GLXBadContext for us if it needs to,
so we can avoid synthesizing an error on the client side.
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7859>
For the DRI backends we factor this out to a dri_common_create_context
method. Indirect gets the same transformation but doesn't use the common
method since it can't rely on DRI being built.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660>
Adam Jackson
Jeremy Huddleston Sequoia
Dave Airlie
Keith Packard
Eric Anholt
Andrii Simiklit