We can't remove all the ifdefs (__DRI_TEX_BUFFER_VERSION) because
configure.ac is only checking for that version of Mesa in the absence
of dri2.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Thanks to configure.ac's check, we know that we have a new enough
dri_interface.h that we don't need to conditionalize all this code.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Skipped present pixmap calls were not setting the mode to
PresentCompleteModeSkip for skipped operations.
Signed-off-by: Keith Packard <keithp@keithp.com>
Presents which are not marked 'queued' and are in the window present
list are waiting for the flip event; discarding those won't work very
well (it'll end up trashing displayed content for the next frame), so
skip over those when looking for duplicate frame presents
Signed-off-by: Keith Packard <keithp@keithp.com>
Check for Async flag and execute immediately if set, otherwise wait
for the next appropriate vblank before copying.
Signed-off-by: Keith Packard <keithp@keithp.com>
This can't happen when GLX is the backing window system, but can
elsewhere. We may as well protect against it at a high level.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We want to advertise the version we implement, not the version the
protocol headers happen to describe.
Reviewed-by: Jasper St. Pierre <<jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We want to advertise the version we implement, not the version the
protocol headers happen to describe.
Reviewed-by: Jasper St. Pierre <<jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
There's nothing to stop a client from sending these requests to screens
without DRI3 support, and if they do, we'll crash. Let's not do that.
Reviewed-by: Jasper St. Pierre <<jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If an touch triggers an async button grab and that grab does not have the
ButtonReleaseMask set, the TouchEnd is never delivered, deliveries is 0 and
the grab is never deactivated.
If the grab is pointer async and keyboard sync, the keyboard events are stuck
in EnqueueEvent until some other pointer event terminates the grab.
Change this to check for the number of listeners. If we're about to deliver a
TouchEnd to a passive pointer grab, the number of listeners is already 1 -
pointer grabs always accept so other listeners were removed.
X.Org Bug 71878 <http://bugs.freedesktop.org/show_bug.cgi?id=71878>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bug #71878 describes a bug resulting in the server ceasing to respond to
keyboard input after a touch event. The problem might be the following:
DeliverTouchBeginEvent tries to deliver an event to a listener of type
LISTENER_POINTER_REGULAR, taking the following if branch,
if (listener->type == LISTENER_POINTER_REGULAR ||
listener->type == LISTENER_POINTER_GRAB) {
rc = DeliverTouchEmulatedEvent(dev, ti, ev, listener, client, win,
grab, xi2mask);
if (rc == Success) {
listener->state = LISTENER_IS_OWNER;
/* async grabs cannot replay, so automatically accept this touch */
if (dev->deviceGrab.grab &&
dev->deviceGrab.fromPassiveGrab &&
dev->deviceGrab.grab->pointerMode == GrabModeAsync)
ActivateEarlyAccept(dev, ti);
}
goto out;
}
DeliverTouchEmulatedEvent succeeds. The deviceGrab meets all
three of the conditions of the inner if, enters
ActivateEarlyAccept which then fails due to,
BUG_RETURN(ti->listeners[0].type != LISTENER_GRAB &&
ti->listeners[0].type != LISTENER_POINTER_GRAB);
That is, despite listener->type == LISTENER_POINTER_REGULAR. With my
non-existent knowledge of XINPUT, it seems like the solution here
might be to only ActivateEarlyAccept when listener->type ==
LISTENER_POINTER_GRAB.
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Newly created windows inherit the pixmap of their parent, similarly,
reparenting a tree inherits the pixmap of the destination tree.
Making present preserve the invariant that unredirected windows always
have the same pixmap as their parent ensures that the above cases work
correctly.
v2: name the recursive function to 'set_tree_pixmap' instead of 'set_window_pixmap'
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
v1: Rewrite by Marc Haesen of the WGL wrapper function generation script to use
Khronos group XML.
v2: Remove -dispatchheader option, since dispatch.h doesn't exist anymore, use
the private glapi interface to construct the GL dispatch table for the native
WGL thunks.
v3:
Rewrite to generate shims for the OpenGL 1.2.1 (GL 1.2 + GL_ARB_imaging
+GL_ARB_multitexture + GL_ARB_texture_compression(?)) functions the server links
directly with rather than libGL.
These shims dispatch to either the mesa GL DLL, or a thunking DLL containing
cdecl-to-stcall wrapper functions for the native GL DLL.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
At the moment we have a mix of ARB and non-ARB suffixed forms for ARB_multitexture functions
e.g. glMultiTexCoord1fvARB and glMultiTexCoord1dv
Consistently use the ARB-suffixed form, assuming that is present in all libGL
which provide the OpenGL 1.2.1 ABI we expect to be able to directly link with.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
/jhbuild/checkout/xorg/xserver/hw/kdrive/ephyr/ephyr.c: In function ‘ephyrProcessMouseMotion’:
/jhbuild/checkout/xorg/xserver/hw/kdrive/ephyr/ephyr.c:946:188: error: ‘ephyrCurScreen’ undeclared (first use in this function)
/jhbuild/checkout/xorg/xserver/hw/kdrive/ephyr/ephyr.c: In function ‘ephyrProcessButtonPress’:
/jhbuild/checkout/xorg/xserver/hw/kdrive/ephyr/ephyr.c:980:186: error: ‘ephyrCurScreen’ undeclared (first use in this function)
/jhbuild/checkout/xorg/xserver/hw/kdrive/ephyr/ephyr.c: In function ‘ephyrProcessButtonRelease’:
/jhbuild/checkout/xorg/xserver/hw/kdrive/ephyr/ephyr.c:1007:186: error: ‘ephyrCurScreen’ undeclared (first use in this function)
Fix ephyr compilation when ./configure'd with --enable-debug after commit
46cf6bf569, some instances of ephyrCurScreen were
not converted to screen->pScreen->myNum.
v2: Don't use a trivial local variable which will be unused when ./configure'd
with --disable-debug
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Adam Jackson <ajax@redhat.com>
CGL doesn't have anything like glXGetProcAddress, and the old code just
called down to dlsym in any case. It's a little mind-warping since
dlopening a framework actually loads multiple dylibs, but that's just
how OSX rolls.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Now that we're calling non-1.2 ABI things by function pointer this is no
longer needed.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
We're meant not to call these by name due to ABI. Rather than try to
generate a bunch of little stub functions that do the lookup, just
inline it all directly into the calling function.
This does not cache results. That's fine, this is not a performance
path, and if we're atop WGL then we effectively have to do this every
time anyway because wglGetProcAddress results are context-dependent.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Jon TURNEY <jon.turney@dronecode.org.uk>
v7: Don't bother making resources for the backing listeners. [keithp]
This is now slightly unlike how other resources are xineramified. We
create N+1 internal damage listeners, one that's a real resource and
reflects the protocol view, and then one per backend screen where the
report function piles onto the protocol view. The internal listeners
are not stored in the resource database directly, they just hang off the
xinerama resource. We don't wrap Subtract at the dispatch level, but we
do extend it for the Xinerama case to clip to the root window geometry.
As a result of the N+1 design here, the damage reports we generate are
not quite minimal. However they are indistinguishable from sequential
rendering events happening before the client hears damage, and we don't
need to add a post-dispatch callback just for this one extension.
Add is probably (still) somewhat broken since it will only hit screen 0,
but Add really only exists for DRI1's sake, and DRI1 disables itself
with Xinerama enabled anyway. In the absence of a use case, I'm leaving
it unwrapped under Xinerama; if someone wants to define how it ought to
work, be my guest.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Root windows in Xinerama are in the coordinate space of their root window
pixmap, not in protocol space.
v2: Only translate for root windows, sice the window shape is
drawable-relative.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Root windows in Xinerama are in the coordinate space of their root
window pixmap, not in protocol space. This fixes 'xcompmgr -n' when
Xinerama is active.
v2: Only translate for root windows, since the clip origin is
drawable-relative.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Say you have two 800x600 screens left/right of each other. A window
that's 200x200 at +700+0 in protocol coordinate space will appear to be
at -100+0 in the coordinate space of the right hand screen. Put another
way: windows are in the coordinate space of their root window pixmap.
We weren't doing this translation for the COW, so when rendering came in
to it you'd see the top-left chunk of the COW on all screens. Cool
effect and all, but wrong.
v2: Only translate when Xinerama is active [keithp]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
damageext wants this so it can intersect subtract requests against the
root window geometry.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
On UEFI machines you'd prefer fbdev to grab efifb instead of vesa trying
to initialize and failing in a way we can't unwind from. On BIOS
machines this is harmless: either there is an fbdev driver and it'll
probably be more capable, or there's not and vesa will kick in anyway.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
... unless you explicitly disabled it with -bs on the command line, or
with the corresponding thing in xorg.conf.
v2: Drop a bogus hunk from compChangeWindowAttributes [vsyrjala]
v3: s/TRUE/WhenMapped/ [jcristau]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Since we're using RedirectAutomatic to do this, we don't actually
preserve contents when unmapped.
v2: Don't say WhenMapped if Composite didn't initialize [vsyrjala]
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
A default timeslice of 20ms means a pathological client can ruin up to
two frames per scheduler tick. And a fifth of a second is just insane.
Pick two different numbers out of the hat. A 5ms slice means you can
probably keep up with two or three abusive clients, and letting it burst
to 15ms should give you about all the timeslice you need for a
fullscreen game (that's doing server-side rendering for some reason).
If you're running on a system with a 10ms granularity on SIGALRM, then
this effectively changes the intervals to 10ms and 30ms. Which is still
better, just not as better.
I suspect this is about as good as we can do without actually going
preemptive, which is an entire other nightmare.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Would only work on ScreenRec 0, which means it's broken.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Among much else Present depends on RANDR types, and RANDR isn't properly
Xinerama-aware yet anyway.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
If we extend __DRI_CORE or __DRI_SWRAST in dri_interface.h to allow a
new version, it shouldn't make old server code retroactively require
the new version from swrast drivers.
Notably, new Mesa defines __DRI_SWRAST version 4, but we still want to
be able to probe version 1 drivers, since we don't use any features
beyond version 1 of the struct.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Those defines are so you can compile-time check "do I have a
dri_interface.h that defines this new field of the struct?" You don't
want the server to claim it implements the new struct just because you
installed a new copy of Mesa.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
