Because some EnterVT code needs to remove it self from the
call chain, we need to fix all of the wrappers to correctly
unwrap/rewrap during the call chain. This is a follow-on to the fix
for bug 27114 in commit 68a9ee8370.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Jesse Barnes <jesse.barnes@intel.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
I built latest server and copied over a mesa 7.8 dri2 driver to use with it,
and it crashed in here starting compiz. Looks like we need to validate the
flush extension is registered before calling invalidate.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a combination of a huge mechanical patch and a few small
fixups required to finish the job. They were reviewed separately, but
because the server does not build without both pieces, I've merged
them together at this time.
The mechanical changes were performed by running the included
'fix-region' script over the whole tree:
$ git ls-files | grep -v '^fix-' | xargs ./fix-region
And then, the white space errors in the resulting patch were fixed
using the provided fix-patch-whitespace script.
$ sh ./fix-patch-whitespace
Thanks to Jamey Sharp for the mighty fine sed-generating sed script.
The hand-done changes involve removing functions from dix/region.c
that duplicate inline functions in include/regionstr.h, along with
their declarations in regionstr.h, mi.h and mispans.h.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
TryClientEvents already did this; this commit just moves the assignment
one level down so that no event source has to worry about sequence
numbers.
...No event source, that is, except XKB, which inexplicably calls
WriteToClient directly for several events.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This lets the DRI2 clients rely on the server to notify them when they
need to get new buffers. Without this, OpenGL clients poll the server
in glViewport() which can be a performance problems and also isn't
completely correct behaviour.
We bump the DRI2 protocol minor to indicate the availability of the
event, which the DRI2 clients can use to avoid polling. This speeds up
various piglit and oglc test cases as well as real applications.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Some pixmaps (window pixmaps and scratch pixmaps) don't have the
drawable->id set and thus DRI2 gets confused when using that field
for looking up the DRI2 drawable. Go back to using privates for getting
at the DRI2 drawable from a DrawablePtr. We need to keep the resource
tracking in place so we can remove the DRI2 drawable when the X resource
it was created for goes away. Additionally, we also now track the DRI2
drawable using a client XID so we can reclaim the DRI2 drawable even if
the client goes before the drawable and doesn't destroy the DRI2 drawable.
Tested-by: Owen W. Taylor <otaylor@fishsoup.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
If we use the #define'd version from dri_interface.h, the server will
require at least that version of the extension. If we're compiling against
a dri_interface.h with a newer version we don't really require, glxdri2
will require a too high version of the extension.
The right approach is to just hard-code the version we need instead of
using the #defines.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The main motivation here is to have the resource system clean up the
DRI2 drawable automatically so glx doesn't have to. Right now, the
glx drawable resource must be destroyed before the X drawable, so that
calling DRI2DestroyDrawable doesn't crash. By making the DRI2
drawable a resource, GLX doesn't have to worry about that and the
resource destruction order becomes irrelevant.
https://bugs.freedesktop.org/show_bug.cgi?id=26394
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
They've been implemented for a while, but we never advertised them. All we
need to do is set the GLX_PBUFFER_BIT in the drawable type fbconfig
field when we're using DRI2.
https://bugs.freedesktop.org/show_bug.cgi?id=26581
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Export DDX swap control status from the DRI2 module and check for it in
GLX when initializing extensions.
Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We broke the __DRI2_FLUSH API since it was never released, but since it's
taking a little longer than expected to get the X server side of the changes
ready, fix things up so it compiles.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Clients would have received swap events regardless of asking for it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This allows clients to easily check for swap completion status in their
main loop.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Adam Jackson <ajax@nwnk.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Support the new DRI2 2.2 protocol requests: DRI2SwapBuffers, DRI2GetMSC,
DRI2WaitMSC, DRI2WaitSBC and DRI2SwapInterval.
These requests allow the server to support the SGI_video_sync,
SGI_swap_interval, and OML_sync_control GLX extensions if DDX support is
present. The new DDX APIs are documented in dri2.h.
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Adam Jackson <ajax@nwnk.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Return the minimum GLX version supported by all screens. Assume that
DRI2 screens have all the required features for GLX 1.4. Assume that
everyone else can only support GLX 1.2.
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This change implements the protocol for DRI2GetBuffersWithFormat, but
the bulk of the differences are the changes to the extension / driver
interface to make this function work. The old CreateBuffers and
DeleteBuffers routines are replaced with CreateBuffer and DeleteBuffer
(both singular).
This allows drivers to allocate buffers for a drawable one at a time.
As a result, 3D drivers can now allocate the (fake) front-buffer for a
window only when it is needed. Since 3D drivers only ask for the
front-buffer on demand, the real front-buffer is always created. This
allows CopyRegion impelemenations of SwapBuffers to continue working.
As with previous version of this code, if the client asks for the
front-buffer for a window, we instead give it the fake front-buffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
When a drawable goes away, we don't destroy the GLX drawable in full,
since it may be current for a context. This means that when the drawable
is destroyed in full later, the backend doesn't get a chance to
destroy resources associated with the drawable (the DRI2Drawable).
With this patch, we destroy the GLX drawable in full when it goes away
and then track down all contexts that reference it and NULL their
pointers.
The number of buffers is likely to change in the future, so having
this as a define is the right way to go.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
