RemoveDevice() frees the DeviceIntPtr, we shouldn't use the pointer after
that
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Running glxinfo under indirect rendering would randomly fail against the
intel driver, as it would create a context with no attribs, and then the
api value would be passed to the driver uninitialised.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Protocol events don't contain pointers, so it's easier to copy everything
over, then swap in-place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Avoid name shadowing warnings, change the event list to a more specific
name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If the grab_window is the barrier window and the client owns the grab,
deliver as normal grabbed event (respecting owner_events). Otherwise,
deliver as usual.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Only deliver to the client that created the barrier, not to other clients.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
x/y for barrier events should contain the actual pointer position.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Instead of having the pointer barrier code enqueue events separately from
GetPointerEvents, pass the event list through and let it add to it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This allows clients to add barriers that extend to the edge of the
screen. Clients are encouraged to use these instead of precise coordinates
in these cases to help prevent pointer leaks.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Since barriers are axis-aligned, we can do the intersection test with
simple interpolation rather than line-segment intersection. This also
helps us out in the future when we want the barriers to extend to be
rays and lines rather than just segments.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This ensures that we always complete an event sequence.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rename a variable. This is to make the diff in the next commit cleaner.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Additionally, add flags when the pointer is released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
We eventually want to send a new notify event on hitbox leave,
which signifies the dawn of a new barrier event ID, so it's
convenient if we can put the code here.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Pointers (and the hands that drive them) aren't very precise, and the
slightest amount of nudging to either side might be enough to reset
the event ID, making clients think they have an entirely new hit. Allow
for a slightly bigger "hit box" before these barriers get reset.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
If we release a barrier, we want to ensure that we block all
other barriers afterwards, rather than capping the limit to
the two nearest barriers.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
This adds support for clients that would like to get a notification
every time a barrier is hit, and allows clients to temporarily release
a barrier so that pointers can go through them, without having to
destroy and recreate barriers.
Based on work by Chris Halse Rogers <chris.halse.rogers@canonical.com>
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is to make future diffs much cleaner. Best viewed with -w.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When we add events, we eventually want to add more state to the
PointerBarrierClient, so return one of these instead of the dummy
public structure that's not very interesting.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than riding on the ConstrainCursorHarder hook, which has
several issues, move to an explicit hook, which will help us with
some RANDR interaction issues.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is completely pointless as far as I can tell.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In order to send events to specific windows associated with the barrier,
we need to move the code that handles barriers to somewhere where it's
easier to construct and send events. Rather than duplicating XSync with
its XSyncSelectAlarm, re-use the existing XI infrastructure.
For now, just move a bunch of code over, rename some things, and initialize
the new structures, but still consider it a separate codebase. Pointer barrier
requests are still handled by XFixes, so this is a weird intermediate state.
It's unknown whether we'll add explicit requests to pointer barriers inside
XI.
Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
There are limits on which client may select for touch events on a given
window, with restrictions being that no two clients can select on the same
device, but narrower selections are allowed, i.e. if one client has
XIAllDevices, a second client may still select for device X.
The current code had a dependency on which client selected first and which
device, resulting in inconsistencies when selecting for events. Fix that,
responding with the right errors regardless of who selected what first.
X.Org Bug 57301 <http://bugs.freedesktop.org/show_bug.cgi?id=57301>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For touch selection conflicts, we need to check not only if the mask is set
for the device, but if it is set for only that specific device (regardless
of XIAll*Devices)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once the TouchEnd appears on the device, the touch is done. If the client
still has a pointer grab, accept it to avoid clients with TouchOwnership
selections to wait indefinitely for the actual touch event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A client with a pointer grab on a touch device must reject the touch when
detactivating the grab while the touch is active. However, such a rejecting
must not trigger a ButtonRelease event to be emulated and sent to the
client.
Set the grabbing listener's state to HAS_END, so we simply skip delivery to
that client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An active grab ungrabbing is the same as rejecting the grab, since the
client is no longer interested in those events. So reject any touch grab,
but do so before actually deactivating since we're interested in the
TouchEnd for the current grabbing client.
A passive grab otoh is _not_ like rejecting a grab, since it deactivates
automatically when the touch ends.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
TouchListenerAcceptReject may be called during normal event processing, but
ProcessInputEvents is not reentrant and calling it here smashes the event
queue.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit regresses dri1 since it moves the drmSetServerInfo from being
called at module load time to extension init time. However DRIScreenInit
relies on this being called before it gets control.
This patches moves the call into DRIScreenInit and seems to work here.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Due to a typo the major version number was passed as minor version to
version_compare().
Regression-from: ffd4874798
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The formatter confused address operators preceded by casts with
bitwise-and expressions, placing spaces on either side of both.
That syntax isn't used by ordinary address operators, however,
so fix them for consistency.
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
