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>
GCC warned about it:
../../../glx/indirect_dispatch_swap.c:85:1: warning: ‘bswap_CARD64’ defined but not used [-Wunused-function]
85 | bswap_CARD64(const void *src)
| ^~~~~~~~~~~~
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.
With autoconf, hashtable support is built along with Xres support.
Yet, glvnd also use it, so when disabling Xres from configure, the
build will fail at link time because hashtable functions are not
available.
Untie the build of hashtable from Xres support, just like meson build
does.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1091
client->errorValue is already set in validGlxFBConfig. Set it in
__glXDisp_CreateContextAttribsARB for consistency.
Signed-off-by: Peter Harris <pharris@opentext.com>
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>
In file included from ../glx/glxdri2.c:35:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
In file included from ../glx/glxdriswrast.c:39:
/usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
#include <drm.h>
^~~~~~~
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>
glxProbeDriver() concatenates __DRI_DRIVER_GET_EXTENSIONS with driver name
to get symbol name for get_extension function. Unfortunately that doesn't
work for drivers that have hyphen in their name, e.g. sun4i-drm --
get_extensions() for these uses underscore instead.
As result dlsym() doesn't find get_extension() function and AIGLX
initialization fails resulting in following message in Xorg.0.log:
(EE) AIGLX error: sun4i-drm does not export required DRI extension
Replace all non-alpha-numeric characters with underscore to fix the issue.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
It's true that the value would always be -1, if it's not zero, but it's
usually zero is the problem. As a result we return failure from
otherwise successful indirect GLX paths, which isn't very nice of us.
This reverts commit 7d33ab0f8c.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/211
This ensures that any prep work for the drawable we're about to read
from is already done before we call down to GetImage. This should be no
functional change as most of the callers with a non-trivial
SourceValidate are already wrapping GetImage and doing the equivalent
thing, but we'll be simplifying that shortly.
More importantly this ensures that if any of that prep work would
generate events - like automatic compositing flushing rendering to a
parent pixmap which then triggers damage - then it happens entirely
before we start writing the GetImage reply header.
Note that we do not do the same for GetSpans, but that's okay. The only
way to get to GetSpans is through miCopyArea or miCopyPlane - where the
callers must already call SourceValidate - or miGetImage - which this
commit now protects with SourceValidate.
Fixes: xorg/xserver#902
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When using mesa with libglvnd support, mesa will no longer install the
gl, glx, egl pkg-config files but instead let libglvnd provide them.
libglvnd maintainers decided to change the versioning as it was
mesa-specific previously. Now the libraries have versions of the API
they expose[1].
This causes problems when building the X server:
checking for glproto >= 1.4.17 gl >= 9.2.0... no
configure: error: Package requirements (glproto >= 1.4.17 gl >= 9.2.0) were not met:
Requested 'gl >= 9.2.0' but version of gl is 1.2
Lower the version requirement to 1.2 to allow building against libglvnd
provided libraries
[1] 0dfaea2bcb
GLX_EXT_import_context allows multiple clients to share the same
indirect context. If you can't create an indirect context, you're
certainly not going to be able to share one. Hide the extension from the
server string if we've disabled indirect contexts.
This turns piglit's tests from fail to skip when indirect contexts are
disabled. Since GLX_EXT_import_context has been supported in
xfree86-derived servers since day 1 (it was included in the initial GLX
code drop from SGI), this is now also a hint to the client that indirect
contexts are unlikely to work at all.
Reviewed-by: Michel Dänzer <michel@daenzer.net>
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.
Commit 56c0a71fdd incremented the
GLXSERVER_VENDOR_ABI_MINOR_VERSION define, but this define was not actually
being used to set glxServer.minorVersion.
Update the initializer for glxServer to use the correct version numbers.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Add a new function, GlxServerExports::setClientScreenVendor, which will change
the vendor that handles GLX requests for a screen, but only for requests from
a specific client.
v2: Increment the GLXVND minor version number.
v3: Note the GLXVND version requirement for setClientScreenVendor.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
When GlxGetXIDMap looks up an unknown XID, it will now look up a vendor based
on the screen number for the XID and the client that sent the current request.
In GlxGetXIDMap, if the XID is for a regular X window, then it won't be in the
(XID -> vendor) mapping, so we have to look up a vendor by screen number.
With this change, GlxGetXIDMap will use the (screen -> vendor) map for
whichever client sent the current request, instead of using the global
(screen -> vendor) map.
Since GlxGetXIDMap doesn't take a ClientPtr argument, GlxDispatchRequest will
store the client for the current request in a global variable. That way, the
ABI for GLXVND doesn't need to change.
v2: Fix an error check in GlxDispatchRequest.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Each client now has its own (screen, vendor) mapping.
Currently, it's just a copy of the global mapping, but later changes will allow
it to change.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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.
None of this was getting compiled because we hadn't defined the macro
(and aren't getting them from <GL/glxext.h> because reasons). Fix that.
Fixes: xorg/xserver#684
Commit 99f0365b "Add a command line argument for disabling indirect GLX"
added a test to check if indirect context are enabled in
`DoCreateContext()` but `__glXDisp_CreateContextAttribsARB()` doesn't
use `DoCreateContext()` and doesn't check if indirect context is
enabled.
As a result, clients can still manage to create indirect contexts using
`glXCreateContextAttribsARB()` even if indirect contexts are disabled,
which can possibly crash Xservers such as Xwayland or Xephyr when the
context is destroyed.
To avoid the issue, check for `enableIndirectGLX` in
`__glXDisp_CreateContextAttribsARB()` as well.
Fixes: 99f0365b "Add a command line argument for disabling indirect GLX"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
The keySize parameter of the hashing/comparison functions was
incorrectly specified to be sizeof(void*), even though the keys of
this hashtable are CARD32.
Fixes address sanitizer failure on 64-bit builds.
Reviewed-by: Adam Jackson <ajax@redhat.com>
fb is happy to do TrueColor to 8bpp drawables, but mesa is not. Depth 12
is the biggest pseudocolor anyone ever really did, and 15 is the least
truecolor.
Without this Xvfb at depth 8 would "have" GLX, but no vendors
would actually back any of the screens. libGL will attempt to call
GLXQueryServerString to figure out the GLX version, and vnd will throw
an error because there's no vendor to dispatch that to, and then clients
crash.
Signed-off-by: Adam Jackson <ajax@redhat.com>
No functional changes, just fixing a tabs vs. space error I noticed
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Otherwise X server crashes if GLX is enabled and Composite disabled. For
example the compIsAlternateVisual function will try to lookup CompScreenPtr
using the CompScreenPrivateKey, but that was never initialized if Composite is
disabled.
Fixes: f84e59a4f4. ("glx: Duplicate relevant fbconfigs for compositing visuals")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104993
Signed-off-by: Michal Srb <msrb@suse.com>
The GLVND layer will destroy all of the vendor handles at the end of each
server generation, but the GLX module then tries to re-use the same (now-freed)
handle in xorgGlxServerInit at the start of the next generation.
In xorgGlxCloseExtension, explicitly destroy the vendor handle and set it to
NULL so that the next call to xorgGlxServerInit will recreate it.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When a callback list is initialized using CreateCallbackList via AddCallback,
the list gets added to the listsToCleanup array, and as a result the list gets
deleted at the end of the server generation.
But, vendor libraries add themselves to that callback list only once, not once
per generation, so if you delete the list, then no vendor will register itself
on the next generation, and GLX breaks.
Instead, use a static CallbackListRec for the extensionInitCallback list. That
way, it doesn't get added to listsToCleanup, and doesn't get deleted during a
reset.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Allow switching to another driver build without a full installation.
Glamor already takes LIBGL_DRIVERS_PATH into account, so this change
makes sure that the same driver is used in both parts of the server.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Ben Crocker <bcrocker@redhat.com>
Reviewed-by: Antoine Martin <antoine@nagafix.co.uk>
Tested-by: Ben Crocker <bcrocker@redhat.com>
These guards were dropped by the commit below, but it turns out they're
needed. Fixes crash on VT switch.
Fixes: d8ec33fe05 ("glx: Use vnd layer for dispatch (v4)")
Bugzilla: https://bugs.freedesktop.org/105233
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
Set the major/minor version it's currently implemented, not the one
provided by the GLXSERVER_VENDOR_ABI_{MAJOR,MINOR}_VERSION macros.
Those are identical for now, but can change in the future.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
malloc can return NULL, unlike GetVendorDispatchFunc. The latter
provides DispatchBadRequest.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-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>
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 is based on an out-of-tree module written by Kyle:
https://github.com/kbrenneman/libglvnd/tree/server-libglx
I (ajax) did a bunch of cosmetic fixes, ported it off xfree86 API,
added request length checks, and fixed a minor bug or two.
v2: Use separate functions to set/get a context tag's private data, and
call the backend's MakeCurrent when a client disconnects to unbind the
context. (Kyle Brenneman)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Commit 91c42093b248 ("glx: Duplicate relevant fbconfigs for
compositing visuals") adds many new depth 32 fbconfigs as
composite visuals. On a X-Screen running at depth 24, this
also adds bgra 10-10-10-2 fbconigs, as they also have
config.rgbBits == 32, but these are not displayable on a
depth 24 screen, leading to visually corrupted desktops
under some compositors, e.g., fdo bug 104597 "Compton
weird colors" when running compton with
"compton --backend glx".
Be more conservative for now and only select fbconfigs with
8 bpc red, green, blue components for composite visuals.
Fixes: 91c42093b248 ("glx: Duplicate relevant fbconfigs for
compositing visuals")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104597
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Keeps us from needing to add glx/ to the include path everywhere, since
we can't add it to the dix include path because the header file names
conflict with glxproxy.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
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>
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>
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>
Previously, before GLX_OML_swap_method was fixed, both the X server and
client ignored the swapMethod fbconfig value, which meant that, if the dri
driver thought it exposed more than one swapMethod, it actually just
exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method
and restricting the choice for built-in visuals to a single swap method
that meant we didn't have that many fbconfigs to choose from when pairing
the compositing visual with an fbconfig, resulting in the fbconfig paired
with the compositing visual becoming too restrictive for some applications,
(at least for kwin). This problem would also happen if the dri driver
only exposed a single swap method to begin with.
So, to make sure the compositing visual gets a good enough fbconfig,
duplicate fbconfigs that are suitable for compositing visuals and make
sure these duplicated fbconfigs can be used only by compositing visuals.
For duplicated fbconfigs not paired with a compositing visual, construct
new compositing visuals, making compositing clients able to choose visuals
/ fbconfig more adapted to their needs.
This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING"
GLX visualtype.
Fixes: 4486d199bd ("glx: Fix visual fbconfig matching with respect to
swap method")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102806
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Tested-By: Nick Sarnie <commendsarnex@gmail.com>
Tested-by: Fredrik Höglund <fredrik@kde.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
String arguments as elements in the array passed to the link_with
argument in meson's executable() functions are not valid and will end up
causing the build file generation to file. This actually ended up
exposing a bug in meson that caused it not to report where in the
meson.build file it was failing:
https://github.com/mesonbuild/meson/pull/2527
The proper way to have a variable that can contain either an empty link
target or an actual link target is:
some_target = []
if some_cond
some_target = static_library(...)
endif
This way if some_cond is False, some_target gets set to [], gets passed
to executable() in the link_with array, and then gets removed by array
flattening.
This also unbreaks Xwayland builds with -Dglx=false, the thing that
originally made me notice this.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk>
For the built in visuals, we'd typically select the "best" fbconfig
without considering the swap method. If the client then requests a
specific swap method, say GLX_SWAP_COPY_OML, it may well happen that the
first fbconfig matching requirements would have been paired with the 32-bit
compositing visual, and the client would render a potentially transparent
window.
Fix this so that we try to match fbconfigs with the same swap method to all
built-in visuals. That would guarantee that selecting a specific swap-
method would not influence the chance of getting a compositing visual.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The swapMethod config member would typically contain an arbitrary value
on older dri drivers. Fix this so that if we detect an illegal value,
return GLX_SWAP_UNDEFINED_OML.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Adam Jackson <ajax@redhat.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>
The function was an empty since 2008 at least. Drop it since no
drivers use it any more.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The symbol is used only internally and is not part of the API/ABI.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
For direct contexts, most context attributes don't require any
particular awareness on the part of the server. Examples include
GLX_ARB_create_context_no_error and GLX_ARB_context_flush_control, where
all of the behavior change lives in the renderer; since that's on the
client side for a direct context, there's no reason for the X server to
validate the attribute.
The context attributes will still be validated on the client side, and
we still validate attributes for indirect contexts since the server
implementation might need to handle them. For example, the indirect
code might internally use ARB_context_flush_control for all contexts, in
which case it would need to manually emit glFlush when the client
switches between two indirect contexts that didn't request the no-flush
attribute.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The scratch GC defaults to the same state as our persistent GCs. Except
for the "draw" GC, which would generate graphics exposures for... well,
no reason really, PutImage doesn't generate graphics exposures.
Signed-off-by: Adam Jackson <ajax@redhat.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>
This appears to be essentially unused. The only known client-side
library for the SELinux extension is xcb, which does not look for the
name "Flask". The "SGI-GLX" alias for GLX appears to be a bit of
superstition at this point, NVIDIA's driver does not expose it and Mesa
does not check for it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
A common meson pattern is to use empty arrays for optional sources and
dependencies, since it generally iterates over trees of arrays looking
for values. A value of '' will actually go looking for ''.
Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The clever pointer tricks were actually not working, and we were doing
the byte-by-byte moves in general. By just doing the memcpy and
obvious byte swap code, we end up generating actual byte swap
instructions, thanks to optimizing compilers.
text data bss dec hex filename
before: 2240807 51552 132016 2424375 24fe37 hw/xfree86/Xorg
after: 2215167 51552 132016 2398735 249a0f hw/xfree86/Xorg
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This dumps a ton of configure-time checks for system endian macros.
Given that we're marking the mixed-endian fixup code as cold, getting
at the system macros is a waste of code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.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>
Should you find yourself using a 16bpp display while also using a
compositor, you poor soul, you may find that your GLX applications
behave strangely; in particular, glxgears will be transparent. This is
because it clears to (0,0,0,0) which is transparent if you honor alpha,
and it will choose the synthetic visual because it has the most
available r/g/b bits.
To avoid this, bump synthetic visuals to a higher (less-preferred)
select group. Unless the client explicitly asks for non-zero alpha bits,
this will prefer any rgb565 visual ahead of the argb8888 visual.
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
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>
Presently the option guards both direct and accelerated indirect GLX. As
such when one toggles it off they end up without any acceleration.
Remove the option all together until we have the time to split/rework
things.
Cc: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
The messages from glxdricommon.c (used by drisw) still have the A, but
at least we're don't have it locally.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Prior to commit f95645c6f7 ("glx: Don't enable EXT_texture_from_pixmap
unconditionally") DRI glx would always advertise EXT_texture_from_pixmap.
That commit moved the setting of the extension in the extension bits from
__glXInitExtensionEnableBits to its callers so that
__glXInitExtensionEnableBits can be used more generally, but at the same
time made the setting of EXT_texture_from_pixmap conditionally on
__DRI_TEX_BUFFER being present.
This has result in an unintended behavior change which breaks e.g.
compositors running on llvmpipe. This commit makes the DRI swrast glx code
advertise EXT_texture_from_pixmap unconditionally again fixing this.
Fixes: f95645c6f7 ("glx: Don't enable EXT_texture_from_pixmap unconditionally")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Only add unconditional advertising of GLX_EXT_texture_from_pixmap
to glxdriswrast.c, do not also add it to glxdri2.c
Olivier Fourdan
Erik Kurzinger
Niveditha Rau
Adam Jackson
qarmin
Jan Beich
Michel Dänzer
Peter Harris
Alan Coopersmith
Vasily Khoruzhick
Marvin Schmidt
Aaron Plattner
Kyle Brenneman
Jon Turney
Vladimir Panteleev
Lyude Paul
Michal Srb
Thierry Reding
Nicolai Hähnle
Michel Dänzer
Emil Velikov
Mario Kleiner
Tapani Pälli
Giuseppe Bilotta
Thomas Hellstrom
Emil Velikov
Jeremy Huddleston Sequoia
Eric Anholt
Hans de Goede