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
If windowsdriproto headers are available, build a Windows-DRI extension,
which supports requests to enable local clients to directly render GL to a
Windows drawable:
- a query to check if WGL is being used on a screen
- a query to map a fbconfigID to a native pixelformatindex
- a query to map a drawable to a native handle
Windows-DRI can only be useful if we are using WGL, so make an note if WGL
is active on a screen.
Make validGlxDrawable() public
Adjust glxWinSetPixelFormat() so it doesn't require a context, just a
screen and config.
That enables factoring out the deferred drawable creation code as
glxWinDeferredCreateDrawable()
Enhance glxWinDeferredCreateDrawable(), so that pixmaps are placed into a
file mapping, so they exist in memory which can be shared with the direct
rendering process.
Currently, this file mapping is accessed by a name generated from the XID.
This will not be unique across multiple server instances. It would perhaps
be better, although more complicated, to use an anonymous file mapping, and
then duplicate the handle for the direct rendering process.
Use glxWinDeferredCreateDrawable() to ensure the native handle exists for
the Windows-DRI query to map a drawable to native handle.
v2:
Various printf format warning fixes
v3:
Fix format warnings on x86
Move some uninteresting windows-dri output to debug log level
v4:
check for windowsdriproto when --enable-windowsdri
use windowsdriproto_CFLAGS
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
>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>
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>
