[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

x11proto-input: Changes to 'upstream-experimental'



 XI2.h              |    1 +
 configure.ac       |    2 +-
 specs/XI2proto.txt |   28 +++++++++++++++++-----------
 3 files changed, 19 insertions(+), 12 deletions(-)

New commits:
commit 1306ccf9f262c0c699bec093ffdc4b6695601599
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Jan 6 13:35:25 2012 +1000

    inputproto 2.1.99.5
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

diff --git a/configure.ac b/configure.ac
index efc5242..abd8355 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
 AC_PREREQ([2.60])
-AC_INIT([InputProto], [2.1.99.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([InputProto], [2.1.99.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 AM_INIT_AUTOMAKE([foreign dist-bzip2])
 AM_MAINTAINER_MODE
 

commit 997ae0343730c66d581fd147741cbe27fbe55af2
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jan 3 09:26:22 2012 +1000

    Set a flag on the pointer-emulating touch event
    
    Toolkits need to know which touch event emulated a pointer event and which
    ones do not. To quote Carlos Garnacho:
    
        GTK+ does client-side windows by default (GdkWindows without a backing X
        window), for this to work the toplevel window in the client needs to
        select for more events that it wouldn't normally select for in order to
        cater for the event masks in such child "windows". This means that
        ideally GTK+ should set the touch events mask in the toplevel, and then
        find out whether the "window" would receive pointer or touch events for
        the sequence emulating the pointer, and perform the emulation itself.
    
    Reported-by: Carlos Garnacho <carlosg@gnome.org>
    Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

diff --git a/XI2.h b/XI2.h
index 4368006..e864b06 100644
--- a/XI2.h
+++ b/XI2.h
@@ -158,6 +158,7 @@
 #define XIPointerEmulated                       (1 << 16)
 /* Device event flags (touch events only) */
 #define XITouchPendingEnd                       (1 << 16)
+#define XITouchEmulatingPointer                 (1 << 17)
 
 /* Touch modes */
 #define XIDirectTouch                           1
diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 8e2eea8..6ab2559 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -505,7 +505,8 @@ window set has been reached, the event is delivered:
 - otherwise, to the next parent window in the window set until a selection has
   been found.
 
-Emulated pointer events will have the PointerEmulated flag set.
+Emulated pointer events will have the PointerEmulated flag set. A touch
+event that emulates pointer events has the TouchEmulatingPointer flag set.
 
 [[glossary-notations]]
 Notations used in this document
@@ -2048,7 +2049,8 @@ For a detailed description of classes, see the XIQueryDevice request.
     DEVICEEVENTFLAGS (all events): none
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
     DEVICEEVENTFLAGS (pointer events only): { PointerEmulated }
-    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
+    DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd,
+                                            TouchEmulatingPointer }
 
 An XIDeviceEvent is generated whenever the logical state of a device
 changes in response to a button press, a button release, a motion, a key
@@ -2108,6 +2110,8 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         accepted or passed on ownership.  The touch will not generate any
         further TouchUpdate events once an event with TouchPendingEnd has been
         received.
+        TouchEmulatingPointer is set on touch events that emulate pointer
+        events.
 
 Modifier state in mods is detailed as follows:
 

commit 5ee845c1bf457159a034111c3d0df584aa600cd6
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jan 3 09:24:38 2012 +1000

    specs: purge leftover TouchAccepted note
    
    This flag does not exist anymore.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Chase Douglas <chase.douglas@canonical.com>

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 7ea2048..8e2eea8 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2102,9 +2102,6 @@ KeyRelease, ButtonPress, ButtonRelease, Motion.
         and 7) if a smooth-scrolling event on the Rel Vert Scroll or
         Rel Horiz Scroll axes was also generated. It is also set on Motion,
         ButtonPress, and ButtonRelease events generated by direct touch devices.
-        TouchAccepted (for TouchEnd events only) means that the current owner
-        of the touch stream has “accepted” it, and this client will not receive
-        any further events from that touch sequence.
         TouchPendingEnd (for touch events only) means that the touch
         has physically ended, however another client still holds a grab, so the
         touch should be considered alive until all grabbing clients have

commit e65ba758c2d4147c3873c63c262db36ec23bba63
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Tue Jan 3 09:23:23 2012 +1000

    specs: only pointer events have a PointerEmulated flag
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Chase Douglas <chase.douglas@canonical.com>

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 2f03b50..7ea2048 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -2047,7 +2047,7 @@ For a detailed description of classes, see the XIQueryDevice request.
 
     DEVICEEVENTFLAGS (all events): none
     DEVICEEVENTFLAGS (key events only): { KeyRepeat }
-    DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated }
+    DEVICEEVENTFLAGS (pointer events only): { PointerEmulated }
     DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd }
 
 An XIDeviceEvent is generated whenever the logical state of a device

commit 9611be0a5bc7f4d583d49d51a0e98d3b9b75fc7a
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Dec 23 18:03:09 2011 +1000

    specs: Clarify rejection for touch events on current owner
    
    The current owner never gets a TouchUpdate(PendingEnd), that event is
    superfluous for the owner. The owner receives a TouchEnd when the touch
    physically ends. If the touch is still active, the owner receives a
    TouchEnd after rejecting the touch.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Chase Douglas <chase.douglas@canonical.com>

diff --git a/specs/XI2proto.txt b/specs/XI2proto.txt
index 0455ed3..2f03b50 100644
--- a/specs/XI2proto.txt
+++ b/specs/XI2proto.txt
@@ -366,11 +366,16 @@ TouchEnd events, and the touch sequence is exclusively delivered to the
 owner from that point on.
 
 If the touch sequence physically ends while the owner of the touch sequence
-has not yet accepted or rejected ownership, all clients receive a
-TouchUpdate event with the TouchPendingEnd flag set. The owner must still
-accept or reject the sequence nonetheless. If the owner rejects the touch
-sequence, the server will still attempt to exhaust all other passive grabs
-and/or event selections looking for a final owner.
+has not yet accepted or rejected ownership, the owner receives a TouchEnd
+event and all other clients receive a TouchUpdate event with the
+TouchPendingEnd flag set. The owner must still accept or reject the sequence
+nonetheless. If the owner rejects the touch sequence, the server will still
+attempt to exhaust all other passive grabs and/or event selections looking
+for a final owner.
+
+If the touch sequence has not physically ended yet and the owner of the
+touch sequence rejects, the owner receives a TouchEnd event and ownership is
+passed to the next client.
 
 Clients may opt for touch events to be delivered before they become the
 owner of the touch sequence. In this case, the logical state of the device (as


Reply to: