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>
Most of the legacy CreateContext paths already did this, this is just
aligning the two so we can implement one in terms of the other.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7660>
Now that we introduced the generic glx_extension_override option,
we can remove the glx_disable_oml_sync_control,
glx_disable_sgi_video_sync, and glx_disable_ext_buffer_age ones.
It seems like the only user for them was the vmwgfx, and only for
Gnome and Compiz which are covered by the default mesa driconf. This
means that it is unlikely for a user to have these options set in
their local driconf file.
Suggested-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7252>
Support for DRI1 is not implemented, but who still uses that?
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
Support for DRI1 is not implemented, but who still uses that?
v2:
- Add the option to the list of new features
- Drop overriding the Xorg-exposed extensions
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
This can be useful for debugging or working around bugs involving
indirect GL.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
This can be useful for debugging or working around bugs such as
Mesa#106 where Wine is expecting to find a visual that isn't
available.
v2:
- split the indirect GL extension override to its own commit
- memset the bitfields to 0 in __glXExtensionsCtrScreen
Reviewed-by: Adam Jackson <ajax@redhat.com>
v3:
- slight rework necessary after splitting the computation of usable
extensions (Ian)
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
Replicate the solution used for OpenGL extensions by introducing
__GLX_EXT_BYTES.
Suggested-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
An upcoming commit will require to find an extension in a list. Rather
than duplicating part of the code from set_glx_extension, split it into
find_extension and set_glx_extension.
NOTE: set_glx_extension is a bit of a misnomer since it is also used
for gl extensions. This is why the find function is named
find_extension rather than find_glx_extension.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7212>
This is a minor bugfix, in that the prior code required that the server
expose either XFree86-DRI or DRI2 to get the name; Xwayland exposed
neither, just DRI3. Now, for DRI2 and DRI3, we just ask the loader. It
also means we report "swrast" for the driver name when that's what we're
using, which is probably a good thing.
v2: Trust the driver name from the server for DRI2 (Michel Dänzer)
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7219>
This is a slight generalization of the existing SGI and MESA swap
control extensions, and a prerequisite for GLX_EXT_swap_control_tear.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6671>
It wouldn't work in any case, as the internal API only stores a signed
int, and GLX_EXT_swap_control_tear will overload the meaning of negative
values so we should avoid ambiguity.
If your application needs a swap interval in excess of ~414.25 days, I'm
very sorry.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6671>
I find the __glX naming convention distasteful for a bunch of reasons,
not least that I expect "vi -t glXBindTexImageEXT" to take me someplace
useful. The functions we're referencing here should not be exported from
libGL (hence the static / _X_HIDDEN) but that's no reason not to name
them correctly.
This does have one possible, very minor, correct functional change,
glXGetMscRateOML now returns Bool (unsigned int) instead of GLboolean
(unsigned char); if your psABI really only writes to a single byte of
the return register when the return type is char-like, then we probably
would not have returned false when we meant to. At least for amd64 this
does not seem to be an issue; the old code wrote 0 to %eax, the new code
does a zero-extended load from %al to %eax (since the internal function
still returns GLboolean).
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6671>
Passes all of `dEQP-EGL.functional.swap_buffers_with_damage.*`:
Passed: 36/54 (66.7%)
Failed: 0/54 (0.0%)
Not supported: 18/54 (33.3%)
Warnings: 0/54 (0.0%)
Waived: 0/54 (0.0%)
The "not supported" ones are the `preserve_buffer_*` tests, which is not
supported on X11/DRI3.
Cc: 20.2 <mesa-stable>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3030
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6132>
This uses a meson builtin to handle -fvisibility=hidden. This is nice
because we don't need to track which languages are used, if C++ is
suddenly added meson just does the right thing.
Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4740>