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>
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>
mask[(MAX_VALUATORS + 7)/8] is larger than data[MAX_VALUATORS], so static
code checkers think we may be running OOB on the data array. Mask is
initialized to 0, so this should not happen, but change it anyway to shut up
code analyzer noise.
X.Org Bug 59939 <http://bugs.freedesktop.org/show_bug.cgi?id=59939>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Instead of guessing what resource type the listener is and what property to
retrieve, store the resource type in the listener directly.
Breaks XIT test cases:
TouchGrabTestMultipleTaps.PassiveGrabPointerEmulationMultipleTouchesFastSuccession
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=56557
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chase Douglas <chase.douglas@ubuntu.com>
This places a pointer to the grab related to a TouchListener directly
in the TouchListener structure rather than hoping to find the grab
later on using the resource ID.
Passive grabs have resource ID in the resource DB so they can be
removed when a client exits, and those resource IDs get copied when
activated, but implicit grabs are constructed on-the-fly and have no
resource DB entry.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Conflicts:
Xi/xichangehierarchy.c
Small conflict with the patch from
Xi: don't use devices after removing them
Was easily resolved by hand.
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
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>
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>
As before GetTouchEvents causes unwanted side effects. Add a new
function GetDixTouchEnd, which generates a touch event from the touch
point. We fill in the event's screen coordinates from the MD's current
sprite position.
Signed-off-by: Thomas Jaeger <ThJaeger@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Button mask should be out-of-band with the emulated
pointer events as touch devices don't truly have
"buttons". Even though, it's handy to have the modifier
mask from the paired keyboard on touch events.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ensure emulated pointer events contain the state that applies before the
event was processed, so the device state must be updated after delivering
such emulated events.
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
exevents.c: In function 'ProcessTouchEvent':
exevents.c:1601:20: warning: too many arguments for format
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If a client is still waiting for the TouchBegin, don't deliver a TouchEnd
event.
X.Org Bug 55738 <http://bugs.freedesktop.org/show_bug.cgi?id=55738>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Thomas Jaeger <thjaeger@gmail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This flag is never set, so checking for it here means that we'll
never release the simulated mouse button press after the user touches
(and releases) the touchscreen for the first time.
Fixes a problem where the XO laptop touchpad became totally
unusable after touching the screen for the first time (since X then
behaved as if the mouse button was held down all the time).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the owner of a touch accepts it, the other listeners must
receive a TouchEnd.
Even though there's code implementing the logic above in
ProcessTouchOwnershipEvent(), DeliverTouchEndEvent() was refusing to send
those TouchEnd events in this situatuation.
Signed-off-by: Daniel d'Andrada <daniel.dandrada@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Daniel Stone <daniel@fooishbar.org>
exevents.c: In function 'DeepCopyFeedbackClasses':
exevents.c:272:20: warning: declaration of 'classes' shadows a previous
local [-Wshadow]
exevents.c:245:16: warning: shadowed declaration is here [-Wshadow]
(and a few more like this)
exevents.c: In function 'DeliverTouchEmulatedEvent':
exevents.c:1442:27: warning: declaration of 'win' shadows a parameter
[-Wshadow]
exevents.c:1404:55: warning: shadowed declaration is here [-Wshadow]
exevents.c:1475:28: warning: declaration of 'listener' shadows a parameter
[-Wshadow]
exevents.c:1403:62: warning: shadowed declaration is here [-Wshadow]
xiselectev.c: In function 'ProcXISelectEvents':
xiselectev.c:178:34: warning: declaration of 'dummy' shadows a previous
local [-Wshadow]
xiselectev.c:91:18: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This is only called from the enterleave implementation, so move it and its
helper functions to there. No functional changes.
Fixes build error introduced in 31174565ec if
building with '-Werror=implicit-function-declaration'
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
If a touch is physically active, the pointer core state should reflect
that the first button is pressed. Currently, this only occurs when there
are active listeners of the touch sequence. By moving the device state
updating to the beginning of touch processing we ensure it is updated
according to the processed physical state no matter what.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently, the touch is only logically ended if the touch has physically
ended. If the touch hasn't physically ended, the touch record is never
ended. If there aren't any more listeners, we don't need to keep the dix
touch record around any more.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
As a special case, if a still physically active pointer emulated touch
has no listeners and the device is explicitly grabbed for pointer
events, create a new dix touch record for the grab only.
This allows for clients to "hand off" grabs. For example, when dragging
a window under compiz the window decorator sees the button press and
then ungrabs the implicit grab. It then tells compiz to grab the device,
and compiz then moves the window with the pointer motion. This is racy,
but is allowed by the input protocol for pointer events when there are
no other clients with a grab on the device.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The function will be used for building a sprite for pointer emulation
after an explicit device grab. This commit refactors the code so that
TouchBuildSprite will function with any event type and moves the checks
to the caller.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fake touch end events are generated by touch acceptance and rejection.
These should not cause implicit pointer grabs to be deactivated.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fake end events are generated by touch acceptance or rejection. These
should not end the touch point.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We still need to generate the touch ownership event to process the
ending of the touch event in the case where the owner has the end
already.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a bit of unimplemented code for touchscreen pointer emulation. A
pointer grabbing client currently never accepts the touch sequence. The
sequence must be accepted once any touch-derived event is irrevocably
delivered to a client.
The first pointer event, derived from a touch begin event, may be caught
in a sync grab and then replayed. This is essentially a revocable
delivery of an event. Thus, we must wait till a non-begin event is
delivered.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code returns a reference to memory that may not actually be
an XI2 mask. Instead, only return a value when an XI2 client has
selected for events.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code checks the core event mask as though it were an XI2
mask. This change fixes the checks so the proper client and event masks
are used.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Issue:
* Two sequential touches (i.e. down, up, down, up)
* Both are grabbed by a touch grab
* Both have a second listener in the form of a pointer grab or selection
* The second and first touches are rejected in that order
The first touch must be pointer emulated before the second touch, so the
second touch must be paused until the first touch is rejected or
accepted and all events are delivered to pointer clients.
This change ensures all pointer emulated events are emitted
sequentially. It necessarily imposes a delay on further touch events
when pointer grabs and selections are used, but there is no way around
it.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just like when we deliver to a touch listener, we must convert a touch
end event to an update event for further clients. This also ensures that
the touch record is not deleted at the end of ProcessTouchEvent().
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After the pointer grab is deactivated, the touch listener record is
updated at the end of DeliverTouchEmulatedEvent. However, the touch
record is ended when the grab is deactivated, so the update to the
listener record is in an array of memory that has been freed.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Preparation work for per-device idle counters.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: James Jones <jajones@nvidia.com>
If there is only one listener of a touch, the listener is a grab, and is
accepted before the touch has ended, the current code will not end the
touch record when the touch does end.
This change adds a listener state for when a touch is accepted but has
not yet ended. We now keep the touch record alive in this state, but end
it when the touch ends.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The VCP may have active touch grabs. The touch records must be kept so
these touch grabs may be accepted/rejected in the future. This means the
touch class list will not represent the touch class of the attached
slave device if it does not have a touch class, but we already were
breaking that assumption by keeping a separate touches array for the
VCP.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The VCP has its own touches array, don't overwrite it when the class is
copied from the SD to the master.
Reported-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
In this case, we have ended the touch because the last owner has
rejected it. We need to return from the function right now so we don't
attempt to dereference another touch client for early acceptance
processing.
Signed-off-by: Chase Douglas <chase.douglas@ubuntu.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Similar to the fix in fcda98c486. This
ensures we show the correct logical state of the buttons in device focus
events too.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This doesn't really implement early accept as it should. Ideally, the
server should send end events to all subsequent touch clients as soon as
an early accept comes in. However, this implementation is still protocol
compliant. We can always improve it later.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This function is mostly correct for early reject usage. With a small
change to pass the client resource explicitly and making the
TouchOwnership event optional, it is usable for all rejection scenarios.
This change exports it for use outside Xi/exevents.c and modifies the
name accordingly.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The server often needs to generate and deliver TouchEnd events for
circumstances including touch grab acceptance and rejection. This change
refactors the code so it can be used more easily.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current code short-circuits around the block that removes the
rejecting listener if it is the only listener left. It also does not
delete the touchpoint record if the touch has not physically ended.
This change ensures the listener is removed under these circumstances.
Signed-off-by: Chase Douglas <chase.douglas@ubuntu.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A touchpoint is ended when no further processing will take place for it.
This includes the situation where there is only one grabbing client, and
the client receives a touch end before it has accepted/rejected the
touchpoint.
This change ensures that a delivered touch end event is converted into a
touch update event under the above scenario. If the event is left as a
touch end event, the touchpoint will be ended in ProcessTouchEvent().
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the device is already grabbed, don't activate the passive grab, it screws
with our event masks. Just deliver to the grabbing client instead.
Reported-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Ownership changes don't get processed directly when they happen, instead the
DIX submits an ownership event which goes through ProcessTouchEvents and
ProcessTouchOwnershipEvents.
Then on the required events are generated and sent to clients.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Includes a hack for implicit grab activation, because integrating this
requires a larger rewrite and I'm not sleeping enough as it is.
Right now, we deliver the event and check before/after if there is an
implicit grab on. If one activated, then store the event in the grab and
switch the listener type to a grab listener.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Does not include pointer emulation handling.
Does include partial ownership handling but not the actual processing of
ownership events.
Note: this commit is a retroactive commit extracted from a series of ~50
commits and may thus appear a bit more complicated than what you'd write out
from scratch.
Pointer processing tree is roughly:
- ProcessOtherEvents
- ProcessTouchEvents
- DeliverTouchEvents
- DeliverTouchBeginEvent|DeliverTouchEndEvent|...
- DeliverOneTouchEvent
Also hooks up the event history playing to the right function now.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Co-authored-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Update the logical button state for pointer-emulating events. Button state
must be kept separate from the ButtonClassRec to avoid clearing the button
state on a touch end if there is a physical button still down.
And obviously don't change the button state if we're currently replaying the
event history for some client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
These structs will be used to store touch-related data, events and
information.
Drivers must call InitTouchClassDeviceStruct to set up a multi-touch capable
device.
Touchpoints for the DDX and the DIX are handled separately - touchpoints
submitted by the driver/DDX will be stored in the DDXTouchPointInfoRec. Once
the touchpoints are processed by the DIX, new TouchPointInfoRecs are created
and stored. This process is already used for pointer events with the
last.valuators field.
Note that this patch does not actually add the generation of touch events,
only the required structs.
TouchListeners are (future) recipients of touch or emulated pointer events.
Each listener is in a state, depending which event they have already
received. The type of listener defines how the listener got to be one.
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
No-one can generated them yet, but if they could, we'd be processing them
like there was no tomorrow.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The are the same as device events internally but require the touch ID
separately from the detail.button field (the protocol uses the detail field
for the touch id).
For simpler integration of pointer emulation we need to set the
detail.button field while keeping the touchid around.
Add the three new touch event types to the various places in the server
where they need to be handled. The actual handling of the events is somewhat
more complicated in most places.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
All the DeepCopy stuff really needs to be shared between the init calls the
drivers use and this code here. Too many bugs by not keeping the two in
sync.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
They achieve the same thing, re-use the more generic InputLevel so we can
convert to/fro easier.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Functional change: for a button mapped to 0, the motionHintWindow is not
updated to the NullWindow anymore. Before it got updated unconditionally to
the button mapping. I have no idea what the practical effect of this is, but
I guess it's closer to the correct behaviour: pressing a button that's
logically disabled now does not disrupt the motion hint delivery.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
'state' is shadowed by the XKB 'state' as well (which feeds into the event
too), so rename this one to clarify that this is the core event state only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Once grabs start having nested memory locations, we can't just use the
GrabRec on the stack anymore, we need to alloc/copy/free the grabs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Does what it says on the box, complements MakeInputMask.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Currently not needed since the InputClientRec is a self-contained struct. As
part of the touch rework that won't be the case in the future and a function
to allocate/free memory appropriately is required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Wherever it's obvious which device we need (keyboard or pointer), use
GetMaster() instead of GetPairedDevice(). It is more reliable in actually
getting the device type we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
They don't have a KeyClassRec, but we must still allow passive grabs on
them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
If we're sending the event for a given device, make sure the deviceid is
that of the device.
This allows callers to use the same DCE for slave and master without having
to fiddle the DCE's internal fields.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Instead of device and master (and just using master), drop the master
argument and let the callers pass in the device the event is to be sent for.
No effective functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
For scroll wheel support, we used to send buttons 4/5 and 6/7 for
horizontal/vertical positive/negative scroll events. For touchpads, we
really want more fine-grained scroll values. GetPointerEvents now
accepts both old-school scroll button presses, and new-style scroll axis
events, while emitting both types of events to support both old and new
clients.
This works with the new XIScrollClass to mark axes as scrolling axes.
Drivers mark any valuators that send scroll events with SetScrollValuator.
(Currently missing: the XIDeviceChangeEvent being sent when a driver changes
a scroll axis at run-time. This can be added later.)
Note: the SCROLL_TYPE enums are intentionally different values to the XI2
proto values to avoid copy/overlapping range bugs.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Relative axes are initialized with 0, -1 but so far this never had any
effect as all users of this function (for relative axes) just set it to the
defaults anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Return errors instead of silently ignoring them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Change the DeviceEvent InternalEvent to use doubles for its valuators,
instead of data and data_frac.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
exevents.c: In function 'UpdateDeviceState':
exevents.c:719:9: warning: variable 'bit' set but not used
[-Wunused-but-set-variable]
exevents.c: In function 'ProcessOtherEvent':
exevents.c:889:22: warning: variable 'v' set but not used
[-Wunused-but-set-variable]
exevents.c:888:17: warning: variable 'k' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
No functional changes, prep work for future changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The macro is sufficient if called during a development cycle, but not
sufficient information when triggered by a user (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=688693).
Expand what this does to print the event content and a backtrace, so at
least we know where we're coming from. Only the first 32 bytes are printed
since if something goes wrong, the event we have is almost certainly an
xEvent or xError, both restricted to 32 bytes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
commit 678f5396c9 only fixed the
initialization, not the copy. After a slave device change, the valuator
were out of alignment again.
X.Org Bug 36119 <http://bugs.freedesktop.org/show_bug.cgi?id=36119>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This removes the struct, but keeps InitAbsoluteClassDeviceStruct as
a no-op and preserves related struct layout.
Signed-off-by: Simon Thum <simon.thum@gmx.de>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is not a straightforward search/replacement due to a long-standing
issue.
dev->u.master is the same field as dev->u.lastSlave. Thus, if dev is a master
device, a check for dev->u.master may give us false positives and false
negatives.
The switch to IsFloating() spells out these cases and modifies the
conditions accordingly to cover both cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
These two were sideeffects of lastSlave being in the same field as the
master. For devices generated by the master device directly, lastSlave was 0
and the device would (with the old checks) be interpreted as floating.
Add the required checks to safeguard against master devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
When a client has selected for Xi 1.x DeviceStateNotify events, they
should receive them when a DeviceFocusIn event is generated. The code
to do this was there, but an incorrect test meant they were never being
sent.
The "type" passed in is the XI2 type, the XI1 type is in event.type.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CheckDeviceGrabs will activate a passive grab for KeyPress and
ButtonPress events. GrabInfoRec::activatingKey contains the keycode
which activated the passive grab, so we can deactivate it later in
ProcessOtherEvents.
Previously, CheckDeviceGrabs relied on its callers to set
activatingKey, which not all callers were doing (I'm looking at you,
ComputeFreezes). Just set it in CheckDeviceGrabs instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since FixUpEventFromWindow only uses the sprite trace to determine the
window stack, pass in a sprite instead of hardcoding the device sprite,
so we can deliver to windows other than the one currently containing the
sprite.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
It is currently assumed that an event button delieved to a master device
corresponds to the slave button states. However, the event button is a
logical (mapped) slave button and slave button states correspond to
physical (unmapped) slave buttons. This leads to incorrect update of the
master button state and incorrect events devlivered to clients. Fix the
situation by taking the slave button map into account when querying a
slave button state.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=24887
Signed-off-by: Eoghan Sherry <ejsherry@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have per-axis mode now. For those bits that still need it (XI 1.x),
assume that the first axis holds the device's mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
