The old code was broken and allowed setting client version >= XIVersion,
this was fixed in the previous patch, but updating the value for XIVersion
broke the tests, so fix the tests too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b6e5c4669e)
Do not allow setting client version to an arbitrary value >= XIVersion.
Fixes a test error with test/xi2/protocol-xiqueryversion.c, introduced by
commit 4360514d1c "Xi: Allow clients to ask for 2.3 and then 2.2 without failing"
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 500e844a24)
As of 4360514d1c, XIQueryVersion supports
requesting versions 2.2+ in random order, only 2.0 and 2.1 are restricted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a5abf790183798ad8aa2c29c056df3647777cfbd)
This allows different sub-systems within the same application to
request different Xi versions without either getting old behaviour
everywhere or simply failing with a BadValue.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 4360514d1c)
XI 1.x only allows for first + num valuators, so if a device sends data for
valuators 0 and 2+ only (i.e. valuator 1 is missing) we still need to get
the data for that from somewhere.
XI 1.x uses the hack of an unset valuator mask to get the right coordinates,
i.e. we set the value but don't set the mask for it so XI2 events have the
right mask.
For an absolute device in relative mode, this broke in b28a1af55c, the
value was now always 0. This wasn't visible on the cursor, only in an XI 1.x
client. The GIMP e.g. sees jumps to x/0 every few events.
Drop the condition introduced in b28a1af55c, data in valuators is always
absolute, regardless of the mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3d87566310)
grab->type is only non-zero for passive grabs. We're checking an active grab
here, so we need to check if the touch mask is set on the grab.
Test case: grab the device, then start two simultaneous touches. The
grabbing client won't see the second touchpoints because grab->type is 0
and the second touch is not an emulating pointer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 4fb686d6a6)
All callers currently ignore the new value, so this patch has no effect.
Inverse call graph:
DeliverTouchEmulatedEvent
DeliverEmulatedMotionEvent Ignores value
DeliverTouchBeginEvent
DeliverTouchEvent
DeliverTouchEvents Ignores value
DeliverTouchEndEvent
DeliverTouchEvent
DeliverTouchEvents Ignores value
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 9978b57b8d)
Ungrabbing a device during an active touch grab rejects the grab. Ungrabbing
a device during an active pointer grab accepts the grab.
Rejection is not really an option for a pointer-emulated grab, if a client
has a button mask on the window it would get a ButtonPress emulated after
UngrabDevice. That is against the core grab behaviour.
X.Org Bug 66720 <http://bugs.freedesktop.org/show_bug.cgi?id=66720>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
(cherry picked from commit 8eeaa74bc2)
This shouldn't have been in the patch
Reported-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit c21344add2)
Too many callers relied on the refcnt being handled correctly. Use a simple
wrapper to handle that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9a5ad65330)
ProcessTouchEvents() calls UDS for all touch events, but if the event type
was switched to TouchUpdate(pending end) UDS is a noop.
Daniel Drake found this can cause stuck buttons if a touch grab is
activated, rejected and the touch event is passed to a regular listener.
This sequence causes the TouchEnd to be changed to TouchUpdate(pending end).
The actual TouchEnd event is later generated by the server once it is passed
to the next listener. UDS is never called for this event, thus the button
remains logically down.
A previous patch suggested for UDS to handle TouchUpdate events [1], however
this would release the button when the first TouchEvent is processed, not
when the last grab has been released (as is the case for sync pointer
grabs). A client may thus have the grab on the device, receive a ButtonPress
but see the button logically up in an XQueryPointer request.
This patch adds a call to UDS to TouchEmitTouchEnd(). The device state must
be updated once a TouchEnd event was sent to the last grabbing listener and
the number of grabs on the touchpoint is 0.
[1] http://patchwork.freedesktop.org/patch/13464/
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 35c2e263db)
The cursor is referenced during CopyGrab(), thus doesn't need to be handled
manually anymore. It does need to be refcounted for temp grabs though.
The oldGrab handling in ProcGrabPointer is a leftover from the cursor in the
grab being refcounted, but the grab itself being a static struct in the
DeviceIntRec. Now that all grabs are copied, this lead to a double-free of
the cursor (Reproduced in Thunderbird, dragging an email twice (or more
often) causes a crash).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 481702101b)
A client may call XIGrabDevice twice, overwriting the existing grab. Thus,
make sure we free the old copy after we copied it. Free it last, to make
sure our refcounts don't run to 0 and inadvertantly free something on the
way.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 3093f78d17)
If we have one listener left but it's not a grab, it cannot be in
LISTENER_HAS_ACCEPTED state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 2566bdd8bc)
TouchListenerGone cleans up if a client disappears. Having this in
FreeGrab() triggers cyclic removal of grabs, emitting wrong events. In
particular, it would clean up a passive grab record while that grab is
active.
Move it to CloseDownClient() instead, cleaning up before we go.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5b00fc5227)
Introduced in xorg-server-1.13.99.901-2-g9ad0fdb. Storing the grab pointer
in the listener turns out to be a bad idea. If the grab is not an active
grab or an implicit grab, the pointer stored is the one to the grab attached
on the window. This grab may be removed if the client calls UngrabButton or
similar while the touch is still active, leaving a dangling pointer.
To avoid this, copy the grab wherever we need to reference it later. This
is also what we do for pointer/keyboard grabs, where we copy the grab as
soon as it becomes active.
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 395124bd27)
Obsolete since 4bc2761ad5. This struct
existed so copying a passive grab could be simply done by
activeGrab = *grab
and thus have a copy of the GrabPtr we'd get from various sources but still
be able to check device->grab for NULL.
Since 4bc2761 activeGrab is a pointer itself and points to the same memory
as grabinfo->grab, leaving us with the potential of dangling pointers if
either calls FreeGrab() and doesn't reset the other one.
There is no reader of activeGrab anyway, so simply removing it is
sufficient.
Note: field is merely renamed to keep the ABI. Should be removed in the
future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5363433a5c)
Change the single if condition in the loop body to a
if (!foo) continue;
and re-indent the rest.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a71a283934)
A sync grab is the owner once it gets events. If it doesn't replay the
event it will get all events from this touch, equivalent to accepting it.
If the touch has ended before XAllowEvents() is called, we also now need to
send the TouchEnd event and clean-up since we won't see anything more from
this touch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 5174b1f982)
No functional changes, this just enables it to be re-used easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit e7f79c48b0)
EmitTouchEnd calls DeliverTouchEvents directly instead of through
public.processInputProc. If a device is frozen, the TouchEnd is
processed while the device is waiting for a XAllowEvents and thus ends the
touch point (and the grab) before the client decided what to do with it. In
the case of ReplayPointer, this loses the event.
This is a hack, but making EmitTouchEnd use processInputProc breaks
approximately everything, especially the touch point is cleaned up during
ProcessTouchEvents. Working around that is a bigger hack than this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0eb9390f60)
If a device is frozen in results to a grab, we need to enqueue the events.
This makes things complicated, and hard to follow since touch events are now
replayed in the history, pushed into EnqueueEvent, then replayed later
during PlayReleasedEvents in response to an XAllowEvents.
While the device is frozen, no touch events are processed, so if there is a
touch client with ownership mask _below_ the grab this will delay the
delivery and potentially screw gesture recognition. However, this is the
behaviour we have already anyway if the top-most client is a sync pgrab or
there is a sync grab active on the device when the TouchBegin was generated.
(also note, such a client would only reliably work in case of ReplayPointer
anyway)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit a7d989d335)
If a touch is pending_finish and we just punted it to the next owner, that
client must receive a TouchEnd event.
If we just punted to the last owner and that owner not a touch grab, we need
to end the touch since this is the last event to be sent, and the client
cannot accept/reject this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 214d11d3fc)
Delivering an event changes the state to LISTENER_IS_OWNER and we thus lose
the information of early acceptance.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 026627fe19)
Async grabs cannot replay events, they cannot reject, so we can do an early
accept here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d905348134)
ActivateEarlyAccept() can only be called from a grabbing client, so we can
ignore the rest. And it's easy enough to get the client from that since
9ad0fdb135.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 8b0d210449)
If a TouchBegin is sent to a core client, that client is now the owner.
By the time the TouchEnd is being processed, the client cannot replay
anymore, so we can assume that this is the final touch end and we can clean
up the touch record.
Note: DeliverTouchEmulatedEvent is called for all listeners and immediately
bails out if the client is not the owner and thus shouldn't yet get the
event. Thus, check the return code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d08bae297f)
ef64b5ee97 (which introduced the
TOUCH_CLIENT_ID check) has a wrong assumption that generated touch events
(TOUCH_CLIENT_ID) should not terminate passive grabs.
This is untrue, a TouchEnd may be generated in response to a TouchReject
higher up. If we _deliver_ an event to a client, terminate the passive grab.
This requires us to count the actually delivered events too (first hunk).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 81554d274f)
If the device is currently grabbed as the result of a passive grab
activating, do not prepend that grab to the listeners (unlike active grabs).
Otherwise, a client with a passive pointer grab will prevent touch grabs
from activating higher up in the window stack.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 363b6387da)
If we only have a single touch-grabbing client, setting the client as owner
would clean up the touch once the TouchEnd was processed. If the client then
calls XIAllowTouches() it will receive a BadValue for the touch ID (since
the internal record is already cleaned up).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9cc45c18ad)
Instead of accessing ti->listener[0] all the time.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit fc504a44d1)
There's no point in turning on outputs connected to GPU screens during initial
configuration. Not only does this cause them to just display black, it also
confuses clients when these screens are attached to a master screen and RandR
reports that the outputs are already on.
Also, don't print the warning about no outputs being found on GPU screens,
since that's expected.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@gmail.com>
(cherry picked from commit dbfeaf7062)
I didn't think we needed this before, but after doing some more
work with reverse optimus it seems like it should be called.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f2fd8ec372)
this allows the pixmap dirty helper to be used for reverse optimus,
where the GPU wants to copy from the shared pixmap to its VRAM copy.
[airlied: slave_dst is wrong name now but pointless ABI churn at this point]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 8fcb9d91b6)
scrn->display is a property of the main screen really, and we don't
want to have the GPU screens use it for anything when picking modes
or a front buffer size.
This fixes a bug where when you plugged a display link device, it
would try and allocate a screen the same size as the current running
one (3360x1050 in this case), which was too big for the device. Avoid
doing this and just pick sizes based on whats plugged into this device.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 16077b81c5)
We should have no problem allowing output/offload from the same slave,
I asserted here, but in order to implement reverse optimus this makes
perfect sense. (reverse optimus is intel outputting to nvidia).
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f0d0d75bfe)
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=59825
Signed-off-by: Piotr Dziwinski <piotrdz@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit cc3d1a5a61)
