summaryrefslogtreecommitdiff
path: root/glx
AgeCommit message (Collapse)AuthorFilesLines
2018-02-12glx: Only assign 8 bpc fbconfigs for composite visuals.Mario Kleiner1-0/+3
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> (cherry picked from commit bebcc8477c8070ade9dd4be7299c718baeab3d7a)
2018-01-17glx: do not pick sRGB config for 32-bit RGBA visualTapani Pälli1-0/+5
This fixes blending issues seen with kwin and gnome-shell when 32bit visual has sRGB capability set. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103699 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103646 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103655 (cherry picked from commit c2954b16c8730c7ed8441fd8dba25900f3aed265)
2017-12-20glx: Duplicate relevant fbconfigs for compositing visualsThomas Hellstrom3-6/+61
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: 4486d199bd3b ("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> (cherry picked from commit f84e59a4f474d22860bac8aec2947798a86db69b)
2017-12-20glx: Fix visual fbconfig matching with respect to swap methodThomas Hellstrom1-0/+9
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> (cherry picked from commit 4486d199bd3bcb5b2b8ad9bc54eb11604d9bd653)
2017-12-20glx: Work around a GLX_OML swap method in older dri driversThomas Hellstrom1-0/+7
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> (cherry picked from commit 0fc26310d5b09213c65f50bde444a1758172b016)
2017-12-20glx: Move Composite's synthetic visuals to a different select groupAdam Jackson1-0/+5
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> (cherry picked from commit ea483af99a6351323afe00a0b630cd63310efdb1)
2017-12-20glx: Send GLX_VISUAL_SELECT_GROUP_SGIX attribute for visualsAdam Jackson1-2/+3
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> (cherry picked from commit 43efaa6e4fd903229dc9c508da4177ad4bbdd4d8)
2017-12-13glx: Fix glXQueryContext for GLX_FBCONFIG_ID and GLX_RENDER_TYPE (v2)Adam Jackson3-1/+8
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> (cherry picked from commit 5d667df6ea1634191a26f9a7c26bc883701d62b0)
2017-12-13glx: Only flush indirect contexts in MakeCurrent (v2)Adam Jackson1-1/+1
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> (cherry picked from commit 307c124d6bcfe26057767b2c0990dc9ac66b9c93)
2017-12-13glx: Fix typos that break GLX_ARB_context_flush_controlAdam Jackson2-2/+2
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> (cherry picked from commit fd0eafb18426da14601d5c0d0a50092c49a7aff8)
2016-10-27glx/dri2: Don't build DRI loader if DRI2 isn't enabledJon Turney1-3/+8
This partially reverts 501d8e2b. Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
2016-10-10glx/dri2: Don't include drm headersAdam Jackson1-2/+0
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>
2016-10-05configure.ac: remove --enable-aiglx optionEmil Velikov1-10/+1
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>
2016-10-05glx: drisw is not accelerated IGLX, reflect that in log messagesEmil Velikov1-3/+3
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>
2016-09-28glx: Always enable EXT_texture_from_pixmap for DRI swrast glxHans de Goede1-2/+1
Prior to commit f95645c6f700 ("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: f95645c6f700 ("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
2016-09-15Add Windows-DRI extensionJon Turney2-1/+4
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>
2016-09-06glx: Fix computation of GLX_X_RENDERABLE fbconfig attributeAdam Jackson6-52/+31
>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>
2016-09-02dri2: Don't make reference to noClientExceptionAdam Jackson1-1/+1
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>
2016-06-21res: Account for GLXPixmap references tooAdam Jackson1-0/+19
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>
2016-06-20glx: avoid memory leak when using indirect renderingGuilherme Quentel Melo1-0/+6
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>
2016-05-11glx: Stop tracking hasUnflushedCommandsAdam Jackson7-23/+1
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>
2016-05-11glx: Remove some redundant zero-init of GLX context stateAdam Jackson2-16/+0
The context is already calloc'd. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-05-11glx/dri2: Implement dri2FlushFrontBuffer explicitlyAdam Jackson1-1/+4
No functional change. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-05-11glx: Code motionAdam Jackson2-67/+67
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>
2016-03-30glx: Implement GLX_EXT_libglvnd (v2)Adam Jackson7-0/+42
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>
2016-03-30glx: Compute the GLX extension string from __glXScreenInitAdam Jackson3-24/+8
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>
2016-03-30glx: Move glx_enable_bits up to the GLX screen base classAdam Jackson3-22/+25
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-03-30glx: Enable GLX 1.4 unconditionallyAdam Jackson6-49/+4
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-03-30glx: Enable GLX_SGI_make_current_read in the coreAdam Jackson3-9/+1
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>
2016-03-30glx: Don't enable EXT_texture_from_pixmap unconditionallyAdam Jackson3-3/+5
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>
2016-03-30glx: Remove server-side mention of GLX_MESA_swap_controlAdam Jackson1-3/+1
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>
2016-03-30glx: Remove default server glx extension stringAdam Jackson3-23/+1
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>
2016-03-10glx: Implement GLX_EXT_fbconfig_packed_floatAdam Jackson4-0/+9
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>
2016-03-10glx: Implement GLX_EXT_stereo_treeAdam Jackson3-1/+11
This is correct as it is, but only because we know no DRI drivers implement stereo. v2: Use new ATTRIB macro Reviewed-by: James Jones <jajones@nvidia.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-03-10glx: Add GLX_SCREEN to the GetDrawableAttributes responseAdam Jackson1-1/+2
libglvnd would like to use this to map from drawable to screen, so it can know which driver to dispatch to. Refer to the spec proposal here: https://lists.freedesktop.org/archives/mesa-dev/2016-March/109543.html Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-03-10glx: Macroize building the attribute list in DoGetDrawableAttributesAdam Jackson1-23/+16
No functional change, just a little easier to read and harder to get wrong. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2016-03-08glx: don't call pGlxDraw->destroy() if AddResource failsJulien Cristau1-7/+2
AddResource will have called DrawableGone, which takes care of the destruction. Reviewed-by: Rémi Cardona <remi@gentoo.org> Signed-off-by: Julien Cristau <jcristau@debian.org>
2016-01-21glx: Fix GLX_EXT_create_context_es2_profile supportAdam Jackson5-26/+13
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>
2015-10-19glx: Fix header length error checking in __glXDisp_RenderLargeJeremy Huddleston1-1/+1
glxcmds.c:2206:46: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare,Semantic Issue] if ((cmdlen = safe_pad(hdr->length)) < 0) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~ Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
2015-10-06glx: Synchronize Xserver glx/rensize.c with mesa src/glx/compsize.cJon TURNEY1-0/+1
Noticed while investigating https://bugs.freedesktop.org/show_bug.cgi?id=30102 Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
2015-09-23glx: fix regression with copy sub buffer disappearingDave Airlie1-2/+3
So copy sub buffer isn't a core extensions it's a driver extension which means we are using totally the wrong interface to query for it here, which means bad things happen when you roll out this code, for instance MESA_copy_sub_buffer stops working. This is just the hack I'm sticking in Fedora to avoid the regression for now, but hopefully will inspire us. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-07-08glx: Implement GLX_ARB_context_flush_controlAdam Jackson7-2/+57
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>
2015-07-08glx/swrast: Do more GLX extension setupAdam Jackson1-3/+34
This gets you nice things like core contexts when using Xvfb. Also, no, MESA_copy_sub_buffer is not enabled automatically. Reviewed-by: James Jones <jajones@nvidia.com> Reviewed-by: Jon Turney <jon.turney@dronecode.org.uk> Signed-off-by: Adam Jackson <ajax@redhat.com>
2015-05-14Revert "glx/dri2: Disable AIGLX if indirect GLX is disabled"Keith Packard1-3/+0
This reverts commit d61ae18074e53c2cdfb13cc37693b526160d6ca7. 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>
2015-05-11Merge remote-tracking branch 'ajax/xserver-next'Keith Packard1-0/+3
2015-05-07glx/dri2: Disable AIGLX if indirect GLX is disabledChris Wilson1-0/+3
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>
2015-04-21Convert glamor & glx to new *allocarray functionsAlan Coopersmith2-10/+8
v2: fixup whitespace Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2014-12-10glx: Add hack for GLX-1.2-style naked windows to GetDrawableAttributesAdam Jackson1-19/+29
Some people like to call this on bare Window XIDs and expect reasonable results. I sure wish they wouldn't, but since they do, if we're given a window without any glx decoration just fill in as much as we can. This means you won't actually get an answer for GLX_FBCONFIG_ID and friends, but there's not much to be done about that, and it matches what NVIDIA's driver seems to do. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54080 Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2014-12-10glx: Dynamically compute attribute slot in GetDrawableAttributesAdam Jackson1-24/+25
No functional change. Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Adam Jackson <ajax@redhat.com>
2014-12-09glx: Add implementation of __GLXContext->loseCurrent for direct ctxtsNeil Roberts1-0/+7
This adds a dummy implementation for the loseCurrent function in __GLXContext for direct contexts which just returns GL_TRUE. Without this then the X server can crash if receives a MakeCurrent message for a direct context because it will attempt to call loseCurrent when cleaning up the client in the callback for ClientStateGone. [ajax: added assumed s-o-b line] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86531 Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Neil Roberts <neil@linux.intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-23 09:57:47 +0000