summaryrefslogtreecommitdiff
path: root/Xi/exevents.c
AgeCommit message (Collapse)AuthorFilesLines
2012-04-26Update device state including when touch record does not existChase Douglas1-3/+3
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> (cherry picked from commit a986f2f30cbe2a00e72ded7315c4951d7703e549)
2012-04-26Ensure touch is ended when last listener is rejectedChase Douglas1-8/+2
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> (cherry picked from commit e175971a6f44d94aa8306dc6b9228ccb2c8a0b4d)
2012-04-26Create a new dix touch record for an emulated touch with no listenersChase Douglas1-0/+28
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> (cherry picked from commit d0449851d1233543c3133d77e0ab7233319cdf5f)
2012-04-26Rename TouchEnsureSprite to TouchBuildSprite and event type checksChase Douglas1-2/+4
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> (cherry picked from commit 3d06bfe93d33cfe6150d8fb0058ee7bc8d80622b)
2012-04-26Don't deactivate implicit pointer grab on fake touch end eventChase Douglas1-0/+1
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> (cherry picked from commit ef64b5ee97099618cf2e2cbbd3e471095695ae24)
2012-04-26End a pointer emulated touch event only on a "real" end eventChase Douglas1-1/+2
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> (cherry picked from commit fc518cd9f59060cc19bb90361767c0f47f0e25eb)
2012-04-26On touch accept, only process end event for owner if it has seen the endChase Douglas1-1/+10
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> (cherry picked from commit 80d7d1ec6a9d61aa96e7d019dc1bee29d90cea34)
2012-04-26Accept touch sequence for pointer listener after second event deliveryChase Douglas1-0/+6
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> (cherry picked from commit cacdb9a74065ccba7d50a82e14abdf04b36c5309)
2012-04-26Only set XI2 mask if pointer emulation is for XI2 clientChase Douglas1-1/+2
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> (cherry picked from commit 93c33403642a3de3c9d141ad7940a7b880846aad)
2012-04-26Check core event mask properly for pointer emulated touch eventsChase Douglas1-6/+12
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> (cherry picked from commit 4c1dfd21937efc6a85fb204a73dd7d7151d54daa)
2012-04-26Ensure sequential touches are pointer emulated sequentiallyChase Douglas1-1/+74
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> (cherry picked from commit 32ece7c09bf0ebc3d99b4078aacebbd44314776a)
2012-04-26Update event type when delivering end event to a pointer listenerChase Douglas1-0/+7
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> (cherry picked from commit 163b0f375d73c05873fb341652de3ed347337828)
2012-04-26Don't update listener after deactivating implicit pointer grabChase Douglas1-1/+3
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> (cherry picked from commit 210cd12c47d063f97915ff23292b61d09abfd73a)
2012-03-30Xi: Fix TouchEnd to TouchUpdate change for one accepted grabChase Douglas1-8/+16
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> (cherry picked from commit 58427e08a4a36ce9e213e4b4fe5249d5db2c764d)
2012-03-27Introduce a consistent coding styleKeith Packard1-908/+869
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> (cherry picked from commit 9838b7032ea9792bec21af424c53c07078636d21)
2012-02-15Keep virtual core pointer touch class around if new slave doesn't have oneChase Douglas1-6/+3
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>
2012-02-15Don't clobber virtual core pointer touches array lengthPeter Hutterer1-5/+13
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>
2012-02-15Don't dereference a touch after it has been ended when punting to next ownerChase Douglas1-0/+1
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>
2012-02-15Focus event button state must show the logical buttons, not physical buttonsChase Douglas1-1/+1
Similar to the fix in fcda98c48610fd507ca0b89c6006a5497d9dc1c9. 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>
2012-02-08Implement touch early acceptChase Douglas1-1/+26
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>
2012-02-08Export TouchEventRejected as TouchRejectedChase Douglas1-11/+27
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>
2012-02-08Factor out TouchEnd generation and deliveryChase Douglas1-66/+37
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>
2012-01-06Remove last listener on touch rejectChase Douglas1-8/+6
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>
2012-01-06Don't end touchpoint if owning client hasn't accepted/rejectedChase Douglas1-2/+4
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>
2011-12-21Xi: only activate the device grab if we don't already have onePeter Hutterer1-2/+2
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>
2011-12-21Xi: add the hooks for passive touch grabsPeter Hutterer1-2/+32
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>
2011-12-21Xi: hook up touch ownership handlingPeter Hutterer1-1/+154
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>
2011-12-21Xi: hook up pointer emulation for emulating touchesPeter Hutterer1-1/+176
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>
2011-12-21Process and deliver touch eventsPeter Hutterer1-0/+401
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>
2011-12-21Xi: make UpdateDeviceState aware of touch eventsPeter Hutterer1-0/+33
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>
2011-12-21dix: when a window disappears, remove it from the touch sprite traceDaniel Stone1-0/+30
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-19input: add a TouchClassRec to the devicesDaniel Stone1-0/+61
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>
2011-12-16Xi: process raw touch eventsPeter Hutterer1-0/+3
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>
2011-12-16Hook up TouchBegin/Update/End eventsPeter Hutterer1-0/+15
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>
2011-12-16Xi: add a FIXMEPeter Hutterer1-0/+2
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>
2011-12-16Xi: split ProcessOtherEvent into ProcessDeviceEventPeter Hutterer1-17/+29
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>
2011-12-13input: replace GRABTYPE_* with the InputLevel enumsPeter Hutterer1-13/+13
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>
2011-12-13Add GrabIsPointerGrab and GrabIsKeyboardGrab helpersPeter Hutterer1-6/+2
No functional changes Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-13dix: split out core state and event state setting into helper functionsPeter Hutterer1-28/+3
no functional changes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-13Xi: split updating button count and state into helper functionsPeter Hutterer1-12/+29
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>
2011-12-13Xi: deduplicate button motion mask settingPeter Hutterer1-12/+25
No functional changes Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-09Xi: rename "state" to "corestate" in ProcessDeviceEventsPeter Hutterer1-5/+5
'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>
2011-12-09Xi: check button mapping value _before_ assigning itPeter Hutterer1-8/+4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-09Xi: skip superfluous castPeter Hutterer1-1/+1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-09input: swap the server over to use the XI2mask structPeter Hutterer1-13/+22
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2011-12-09dix: allocate temporary grabs on the heapPeter Hutterer1-12/+17
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>
2011-11-29Xi: add FreeInputMask functionPeter Hutterer1-2/+10
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>
2011-11-29Xi: add helper functions to alloc/free InputClientPtrsPeter Hutterer1-5/+18
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>
2011-11-09input: replace remaining GetPairedDevice() with GetMaster()Peter Hutterer1-3/+3
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>
2011-11-09Xi: allow passive keygrabs on the XIAll(Master)Devices fake devicesPeter Hutterer1-1/+1
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-06-06 11:35:27 +0000