diff options
Diffstat (limited to 'x11-proto/inputproto')
| -rw-r--r-- | x11-proto/inputproto/Manifest | 6 | ||||
| -rw-r--r-- | x11-proto/inputproto/files/inputproto-2.0.1-xi2.1.patch | 943 | ||||
| -rw-r--r-- | x11-proto/inputproto/files/inputproto-2.0.2-xi2.1.patch | 191 | ||||
| -rw-r--r-- | x11-proto/inputproto/inputproto-2.0.1-r1.ebuild | 30 | ||||
| -rw-r--r-- | x11-proto/inputproto/inputproto-2.0.2-r1.ebuild | 27 |
5 files changed, 1197 insertions, 0 deletions
diff --git a/x11-proto/inputproto/Manifest b/x11-proto/inputproto/Manifest new file mode 100644 index 0000000..98b6324 --- /dev/null +++ b/x11-proto/inputproto/Manifest @@ -0,0 +1,6 @@ +AUX inputproto-2.0.1-xi2.1.patch 43399 RMD160 5052e0b6865b7beda0e1bdd21fe017bf2a6b1020 SHA1 4ce61ea1d4cfefd6800e7a01b428ba20a4d50b11 SHA256 5bc037a3e9a0b65fa23abd0aceed881f1cdd41e0b70a31f40729595dd34a4c9a +AUX inputproto-2.0.2-xi2.1.patch 7387 RMD160 b3b07056cb2040c8e8385138730a51839fb81829 SHA1 a700bf44de61fa04d932e739128548508afd5717 SHA256 0d2298bdfeb85d8c53220837f4cfbfdcf8977d89f901203a790c191b4b473b09 +DIST inputproto-2.0.1.tar.bz2 152547 RMD160 2da79ca35dca7a84a91db6af3e6278b30bc4da5f SHA1 9c11b99b7cccceafa6b4235a3084523fb7cb4621 SHA256 63663dd88df812738e0efdc52a18868c0756128f09748cbe89c8ec6d17124a44 +DIST inputproto-2.0.2.tar.bz2 155535 RMD160 0e232294719ec25386a1a606776a39641d1cd30a SHA1 a34c01c67aa2ed9058ff19ace0041978b1d8d711 SHA256 64222a590ad4a62a3c8d57805379451769e3329cc5c8c5c1f1fc0d1529ebf005 +EBUILD inputproto-2.0.1-r1.ebuild 809 RMD160 9307e37b77c0184bb1a54d164024adc1b1d5e775 SHA1 0fca9540f7fbfb9045148a4ebebb438cb6e87f51 SHA256 0677969f44fdbacb4d6c4b4390c3ee2d6916897e81828a1a32e31d8d85eccb11 +EBUILD inputproto-2.0.2-r1.ebuild 795 RMD160 cda655ff6941e94608a5b0339af4f67cdd4ae9ab SHA1 420f8a30e4482862b3798ddef0c670ccbc3041b3 SHA256 9f48dc2bbd2e166bc5eab78d8ef8a97825816299acc30edd46885797cdc8e3bb diff --git a/x11-proto/inputproto/files/inputproto-2.0.1-xi2.1.patch b/x11-proto/inputproto/files/inputproto-2.0.1-xi2.1.patch new file mode 100644 index 0000000..05de542 --- /dev/null +++ b/x11-proto/inputproto/files/inputproto-2.0.1-xi2.1.patch @@ -0,0 +1,943 @@ +--- a/XI2.h ++++ b/XI2.h +@@ -32,10 +32,12 @@ + #define Dont_Check 0 + #endif + #define XInput_2_0 7 ++#define XInput_2_1 8 + + + #define XI_2_Major 2 + #define XI_2_Minor 0 ++#define XI_2_1_Minor 1 + + /* Property event flags */ + #define XIPropertyDeleted 0 +@@ -65,6 +67,8 @@ + #define XIGrabtypeKeycode 1 + #define XIGrabtypeEnter 2 + #define XIGrabtypeFocusIn 3 ++#define XIGrabtypeTouchBegin 4 ++#define XIGrabtypeTouchBeginInert 5 + + /* Passive grab modifier */ + #define XIAnyModifier (1U << 31) +@@ -79,6 +83,11 @@ + #define XIAsyncPair 4 + #define XISyncPair 5 + ++/* XIAllowTouchEvents bitmask event-modes */ ++#define XITouchOwnerAccept (1 << 0) ++#define XITouchOwnerRejectEnd (1 << 1) ++#define XITouchOwnerRejectContinue (1 << 2) ++ + /* DeviceChangedEvent change reasons */ + #define XISlaveSwitch 1 + #define XIDeviceChange 2 +@@ -113,15 +122,27 @@ + #define XISlaveKeyboard 4 + #define XIFloatingSlave 5 + +-/* Device classes */ ++/* Device classes: classes that are not identical to Xi 1.x classes must be ++ * numbered starting from 8. */ + #define XIKeyClass 0 + #define XIButtonClass 1 + #define XIValuatorClass 2 ++#define XITouchClass 8 ++#define XITouchValuatorClass 9 + + /* Device event flags (common) */ + /* Device event flags (key events only) */ + #define XIKeyRepeat (1 << 16) +-/* Device event flags (pointer events only) */ ++/* Device event flags (pointer and touch events only) */ ++#define XIPointerEmulated (1 << 16) ++/* Device event flags (touch events only) */ ++#define XITouchPendingEnd (1 << 17) ++ ++/* Touch modes */ ++#define XIDirectTouch 1 ++#define XIDependentTouch 2 ++#define XIIndependentPointer 3 ++#define XISemiMultitouch 4 + + /* XI2 event mask macros */ + #define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7))) +@@ -151,7 +172,12 @@ + #define XI_RawButtonPress 15 + #define XI_RawButtonRelease 16 + #define XI_RawMotion 17 +-#define XI_LASTEVENT XI_RawMotion ++#define XI_TouchBegin 18 ++#define XI_TouchEnd 19 ++#define XI_TouchOwnership 20 ++#define XI_TouchUpdate 21 ++#define XI_TouchUpdateUnowned 22 ++#define XI_LASTEVENT XI_TouchUpdateUnowned + /* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value + * as XI_LASTEVENT if the server is supposed to handle masks etc. for this + * type of event. */ +@@ -177,5 +203,10 @@ + #define XI_RawButtonPressMask (1 << XI_RawButtonPress) + #define XI_RawButtonReleaseMask (1 << XI_RawButtonRelease) + #define XI_RawMotionMask (1 << XI_RawMotion) ++#define XI_TouchBeginMask (1 << XI_TouchBegin) ++#define XI_TouchEndMask (1 << XI_TouchEnd) ++#define XI_TouchOwnershipChangedMask (1 << XI_TouchOwnershipChanged) ++#define XI_TouchUpdateMask (1 << XI_TouchUpdate) ++#define XI_TouchUpdateUnownedMask (1 << XI_TouchUpdateUnowned) + + #endif /* _XI2_H_ */ +--- a/XI2proto.h ++++ b/XI2proto.h +@@ -60,6 +60,7 @@ + #include <X11/Xproto.h> + #include <X11/X.h> + #include <X11/extensions/XI2.h> ++#include <stdint.h> + + /* make sure types have right sizes for protocol structures. */ + #define Window uint32_t +@@ -91,9 +92,10 @@ + #define X_XIDeleteProperty 58 + #define X_XIGetProperty 59 + #define X_XIGetSelectedEvents 60 ++#define X_XIAllowTouchEvents 61 + + /** Number of XI requests */ +-#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1) ++#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1) + /** Number of XI2 events */ + #define XI2EVENTS (XI_LASTEVENT + 1) + +@@ -187,6 +189,31 @@ typedef struct { + uint16_t pad2; + } xXIValuatorInfo; + ++/** ++ * Denotes multitouch capability on a device. ++ */ ++typedef struct { ++ uint16_t type; /**< Always TouchClass */ ++ uint16_t length; /**< Length in 4 byte units */ ++ uint16_t sourceid; /**< source device for this class */ ++ uint8_t mode; /**< DirectTouch or DependentTouch */ ++ uint8_t num_touches; /**< Maximum number of touches (0==unlimited) */ ++} xXITouchInfo; ++ ++/** ++ * Denotes a multitouch valuator capability on a device. ++ * One XITouchValuatorInfo describes exactly one valuator (axis) on the device. ++ */ ++typedef struct { ++ uint16_t type; /**< Always TouchValuatorClass */ ++ uint16_t length; /**< Length in 4 byte units */ ++ uint16_t sourceid; /**< source device for this class */ ++ uint16_t number; /**< Valuator number */ ++ Atom label; /**< Axis label */ ++ FP3232 min; /**< Min value */ ++ FP3232 max; /**< Max value */ ++ uint32_t resolution; /**< Resolutions in units/m */ ++} xXITouchValuatorInfo; + + /** + * Used to select for events on a given window. +@@ -771,6 +798,20 @@ typedef struct { + } xXIGetPropertyReply; + #define sz_xXIGetPropertyReply 32 + ++/** ++ * Accept or reject a grabbed touch sequence. ++ */ ++typedef struct { ++ uint8_t reqType; ++ uint8_t ReqType; /**< Always ::X_XIAllowTouchEvents */ ++ uint16_t length; /**< Length in 4 byte units */ ++ uint32_t touchid; ++ uint16_t deviceid; ++ uint8_t mode; /**< bitmask */ ++ uint8_t pad; ++} xXIAllowTouchEventsReq; ++#define sz_xXIAllowTouchEventsReq 12 ++ + /************************************************************************************* + * * + * EVENTS * +@@ -856,7 +897,27 @@ typedef struct + } xXIDeviceChangedEvent; + + /** +- * Default input event for pointer or keyboard input. ++ * The owner of a touch stream has passed on ownership to another client. ++ */ ++typedef struct ++{ ++ uint8_t type; /**< Always GenericEvent */ ++ uint8_t extension; /**< XI extension offset */ ++ uint16_t sequenceNumber; ++ uint32_t length; /**< Length in 4 byte units */ ++ uint16_t evtype; /**< XI_TouchOwnership */ ++ uint16_t deviceid; /**< Device that has changed */ ++ Time time; ++ uint16_t sourceid; /**< Source of the new classes */ ++ uint16_t pad0; ++ uint32_t touchid; ++ uint32_t flags; ++ uint32_t pad1; ++ uint32_t pad2; ++} xXITouchOwnershipEvent; ++ ++/** ++ * Default input event for pointer, keyboard or touch input. + */ + typedef struct + { +--- a/XI2proto.txt ++++ b/XI2proto.txt +@@ -1,11 +1,20 @@ + + The X Input Extension + Version 2.0 ++ Version 2.1 + + Peter Hutterer + peter.hutterer@redhat.com + Red Hat, Inc. + ++ Daniel Stone ++ daniel@fooishbar.org ++ Collabora, Ltd. ++ ++ Chase Douglas ++ chase.douglas@canonical.com ++ Canonical, Ltd. ++ + + + 1. Introduction +@@ -31,6 +40,41 @@ used on applications employing the core + issues by enabling devices to be both extended and core devices and providing + device information in each event (with the exception of core events). + ++1.1 X Input Extension version 2.1 (XI 2.1) ++XI 2.1 introduces support for multi-touch devices. The traditional ++pointer/keyboard approach enforced by XI 2.0 with the master/slave device ++hierarchy is not always suitable for multi-touch devices that can provide a ++dynamic number of multiple independent input points per physical device. ++Furthermore, as such devices are often direct input devices (e.g. touchscreens, ++able to focus without a pointer), the virtual abstraction of master devices is ++not always necessary. ++ ++The additions in XI 2.1 aim to: ++- support a dynamic number of simultaneous touch points, ++- support devices that are both multi-touch and traditional pointer devices, ++- while supporting pre-XI2.1 clients through emulation of XInput and core ++ pointer events. ++ ++XI 2.1 caters for two modes of touch input devices: ++- direct multi-touch input devices such as touch screens. These devices ++ provide independent touchpoints that can occur anywhere on the screen and ++ are usually the result of direct touch interaction. ++- indirect touch input devices such as multi-touch trackpads. These devices ++ provide independent touchpoints that may need to be interpreted ++ relative to the current position of the pointer on that same device. Such ++ interactions are usually the result of a gesture performed on the device. ++ ++A device may change its touch mode at runtime. Clients are informed which ++type of touch device they are dealing with. See XIQueryDevice for more ++information. ++ ++Touch device support is only available to clients supporting version 2.1 or ++later of the X Input Extension. Clients must use the XIQueryVersion request to ++announce support of this version. ++ ++XI 2.1 requires devices to track touch points over time. Devices that cannot ++do so in hardware must employ software trackers to be usable with XI 2.1. ++ + ❧❧❧❧❧❧❧❧❧❧❧ + + 2. Notations used in this document +@@ -149,7 +193,150 @@ to P is only attempted if neither the XI + delivered on W. Once an event has been delivered as either XI or core event, + event processing stops. + +-4.4. The ClientPointer principle ++4.4 Touch device support ++ ++4.4.1 Touch event sequences ++ ++Touch event processing differs from normal event processing in a few ways, ++most notably in that touch events are processed partially out-of-band from ++pointer and keyboard events. ++ ++Touch input follows a three-stage cycle: init - move - move - ... - destroy, ++i.e. “init” the sequence by touching the device, “move” the current touch ++location any number of times, and finally “destroy” the sequence by ceasing ++to touch the device. The init and destroy stage of this sequence are always ++present, while the move stage is optional. Within this document, the term ++"touch sequence" is used to describe the above chain of events. A client ++wishing to receive touch events must register for at least TouchBegin, ++TouchUpdate, and TouchEnd simultaneously. It may also select for ++TouchUpdateUnowned and TouchOwnership events if it wants to receive the full ++touch stream while other clients own or have active grabs involving the touch. ++An example of this usage is a touch painting program that paints touches while ++a gesture recognizer has an active grab. Such clients must be able to undo state ++if the touch ends without the client receiving ownership of the touch. ++ ++A touch sequence is only considered to be meaningful in its entirety: clients ++may not capture part of a touch sequence, interpret only that part, and then ++pass a partial touch sequence on to the next client. To this end, all clients ++with “grabs” on the window hierarchy for a touch sequence receive events from ++that touch sequence, as well as potentially the client with the deepest ++selection (i.e. furthest from the root window). Clients currently in control of ++the touch sequence receive TouchUpdate events, whereas clients not in control ++receive receive TouchUpdateUnowned events. ++ ++Touch grabs are similar to standard input event grabs in that they take ++precedence over selections and are searched from the root window to the child ++window. The first grab found for a touch sequence will be the owner of that ++touch sequence, however events for that touch sequence will continue to be ++delivered to all clients with grabs in the window tree, as well as potentially ++the client with the deepest selection. The first client may either “accept” the ++touch, which claims the touch sequence and stops delivery to all other clients ++for the duration of the touch sequence, or “reject” the touch sequence, which ++will remove that client from the delivery set and pass ownership on to the ++next client. When a client, including the initial owner, becomes the owner of a ++touch, it will receive a TouchOwnership event. When an owning client accepts a ++touch, further clients receiving unowned events will receive TouchEnd events. ++ ++Clients selecting for touch events may select for either unowned events or only ++owned events. The event stream for an unowned selection is identical to a touch ++grab. When a client does not select for unowned and ownership events, it will ++receive a TouchBegin event when it becomes the owner of a touch stream. ++TouchUpdate and TouchEnd events will be received in the same manner as for touch ++grabs. ++ ++A TouchEnd event will always be sent to a client when it will receive no more ++events from a particular touch, regardless of why (grab or selection removed, ++owner accepted, the client having rejected that touch, etc). ++ ++4.4.2 Touch device modes ++ ++Touch devices come in many different forms with varying capabilities. The ++following device modes are defined for this protocol: ++ ++DirectTouch: ++ These devices map their input region to a subset of the screen region. Touch ++ events are delivered according to where the touch occurs in the mapped ++ screen region. An example of a DirectTouch device is a touchscreen. ++ ++DependentTouch: ++ These devices do not have a direct correlation between a touch location and ++ a position on the screen. Touch events are delivered according to the ++ location of the pointer on screen. An Example of a DependentTouch device ++ is a trackpad. ++ ++IndependentPointer: ++ These devices do not have any correlation between touch events and pointer ++ events. IndependentPointer devices are a subset of DependentTouch devices. ++ An example of an IndependentPointer device is a mouse with a touch surface. ++ ++SemiMultitouch: ++ These devices may report touch events that correlate to the two opposite ++ corners of the bounding box of all touches. The number of active touch ++ sequences represents the number of touches on the device, and the position ++ of any given touch event will be equal to either of the two corners of the ++ bounding box. However, the physical location of the touches is unknown. ++ SemiMultitouch devices are a subset of DependentTouch devices. Although ++ DirectTouch and IndependentPointer devices may also be SemiMultitouch ++ devices, such devices are not allowed through this protocol. ++ ++A device is identified as only one of the device modes above at any time. For ++the purposes of this protocol, IndependentPointer and SemiMultitouch devices are ++treated the same as DependentTouch devices unless stated otherwise. ++ ++4.4.3 Touch event delivery ++ ++Window sets for event propagation for direct device touches contain the windows ++from the root to the child in which the touch originated. ++ ++Dependent device window sets depend on whether other touches are active. For ++the first dependent touch on a device, the window set contains the windows from ++the root to the current window underneath the position of the device's pointer. ++For subsequent touches on the device, the window set is identical to the window ++set of the first touch. Once all touches have been released, the window set is ++reset and re-calculated on the first subsequent touch. ++ ++The delivery of touch events is not changed by any modifications to the window ++hierarchy after the window set has been determined for the touch, nor is it ++affected by new grabs or selections. ++ ++No touches from a dependent device may begin while the device is floating, as ++it does not have an associated pointer position to focus events. ++ ++Many touch devices will emit pointer events as well, usually by mapping one ++touch sequence to pointer events. In these cases, events for both the pointer ++and its associated touch sequence will have the XIPointerEmulated flag set. ++ ++4.4.4 Pointer emulation for direct touch devices ++ ++In order to facilitate backwards compatibility with legacy clients, direct touch ++devices will emulate pointer events. Pointer emulation events will only be ++delivered through the attached master device; no pointer events will be emulated ++for floating touch devices. Further, only one touch from any attached slave ++touch device may be emulated per master device at any time. ++ ++A touch event stream must be delivered to clients in a mutually exclusive ++fashion. This extends to emulated pointer events. For the purposes of ++exclusivity, emulated pointer events between an emulated button press and ++button release are considered. An emulated button press event is considered ++exclusively delivered once it has been delivered through an event selection, an ++asynchronous pointer grab, or it and a further event are delivered through a ++synchronous pointer grab. ++ ++Touch and pointer grabs are also mutually exclusive. For a given window, any ++touch grab is activated first. If the touch grab is rejected, the pointer grab ++is activated. If an emulated button press event is exclusively delivered to the ++grabbing client as outlined above, the touch sequence is ended for all clients ++still listening for unowned events. Otherwise, when the pointer stream is ++replayed the next window in the window set is checked for touch grabs. ++ ++If the touch sequence is not exclusively delivered to any client through a grab, ++the touch and emulated pointer events may be delivered to clients selecting for ++the events. Event propagation for the touch sequence ends at the first client ++selecting for touch and/or pointer events. Note that a client may receive both ++touch and emulated pointer events for the same touch sequence through event ++selection. ++ ++4.5. The ClientPointer principle + + Many core protocol and some extension requests are ambiguous when multiple + master devices are available (e.g. QueryPointer does not specfy which pointer). +@@ -271,7 +458,7 @@ are required to be 0. + name: LISTofCHAR8 + classes: LISTofCLASS } + +- CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS } ++ CLASS { BUTTONCLASS, KEYCLASS, AXISCLASS, TOUCHCLASS*, TOUCHAXISCLASS* } + + BUTTONCLASS { type: ButtonClass + length: CARD16 +@@ -296,6 +483,27 @@ are required to be 0. + value: FP3232 + resolution: CARD32 } + ++ TOUCHCLASS* { type: TouchClass ++ length: CARD16 ++ sourceid: CARD16 ++ mode: TOUCHMODE ++ num_touches: CARD16 } ++ ++ TOUCHAXISCLASS* { ++ type: TouchAxisClass ++ length: CARD16 ++ sourceid: CARD16 ++ axisnumber: CARD16 ++ label: ATOM ++ min: FP3232 ++ max: FP3232 ++ resolution: CARD32 } ++ ++ TOUCHMODE* { DirectTouch, DependentTouch, IndependentPointer, ++ SemiMultitouch } ++ ++ * since XI 2.1 ++ + XIQueryDevice details information about the requested input devices. + + devices +@@ -397,6 +605,50 @@ are required to be 0. + An axis in Relative mode may specify min and max as a hint to the + client. If no min and max information is available, both must be 0. + ++ XI 2.1: ++ ++ TouchClass: ++ type ++ Always TouchClass. ++ length ++ Length in 4 byte units. ++ sourceid ++ The device this class originates from. ++ mode ++ The device type of the touch device. ++ num_touches ++ The maximum number of simultaneous touchpoints the device may send. ++ If num_touches is 0, the number of supported touches is unknown or ++ unlimited. ++ ++ A device with a TouchClass must provide one or more TOUCHAXISCLASS ++ specifiers. ++ ++ TouchAxisClass: ++ type ++ Always TouchAxisClass. ++ length ++ Length in 4 byte units. ++ sourceid ++ The device this class originates from. ++ axisnumber ++ Axis number of this axis. The axis number is in device-native ++ order and potential axis mappings are ignored. ++ label ++ Atom specifying the axis name. An Atom of None specifies an unlabeled ++ axis. ++ min ++ Minimum value for this axis. ++ max ++ Maximum value for this axis. ++ resolution ++ Resolution in counts/meter. ++ ++ Devices generating touch events must provide exactly one TouchClass and ++ two or more TouchAxisClasses. TouchAxisClasses and AxisClasses are not ++ interchangable. A TouchAxisClass may only be part of a touch event, ++ whereas an AxisClass may only be part of non-touch events. ++ + ┌─── + XISelectEvents + window: Window +@@ -439,6 +691,14 @@ are required to be 0. + The mask for XIHierarchyEvents may only be selected for XIAllDevices. + Setting it for any other device results in a BadValue error. + ++ A client selecting for any of XI_TouchBegin, XI_TouchOwnership, ++ XI_TouchUpdate or XI_TouchEnd must select for all three events at the ++ same time, else BadValue will be returned. A client selecting for ++ XI_TouchUpdateUnowned must select for all three of the other touch ++ events. If the selection for these touch events overlaps a current ++ selection by another client (e.g. selecting for a specific device when ++ another client has a selection for XIAllDevices), a BadAccess error occurs. ++ + ┌─── + XIGetSelectedEvents + window: Window +@@ -794,7 +1054,8 @@ are required to be 0. + This request actively grabs control of the specified input device. Further + input events from this device are reported only to the grabbing client. + This request overides any previous active grab by this client for this +- device. ++ device. This request does not, however, affect the processing of XI 2.1 ++ touch events. + + deviceid + The device to grab. +@@ -999,7 +1260,8 @@ are required to be 0. + └─── + + GRABTYPE { GrabtypeButton, GrabtypeKeycode, GrabtypeEnter, +- GrabtypeFocusIn} ++ GrabtypeFocusIn, GrabtypeTouchBegin, ++ GrabtypeTouchBeginInert } + + GRABMODIFIERINFO { status: Access + modifiers: CARD32 } +@@ -1015,7 +1277,8 @@ are required to be 0. + AllMasterDevices. + detail + The button number, or key symbol to grab for. +- Must be 0 for GrabtypeEnter and GrabtypeFocusIn. ++ Must be 0 for GrabtypeEnter, GrabtypeFocusIn, and ++ GrabtypeTouchBegin. + grab_type + The type of grab to establish. + grab_window +@@ -1030,6 +1293,8 @@ are required to be 0. + releasing XIAllowEvents request or until the device grab is + released. Actual device input events are not lost while the device + is frozen; they are simply queued for later processing. ++ Must be Asynchronous for GrabtypeTouchBegin and ++ GrabtypeTouchBeginInert (see section 4.4). + mask_len + Length of mask in 4 byte units. + mask +@@ -1087,6 +1352,16 @@ are required to be 0. + - a passive grab of the same grab_type + modifier combination does not + does not exist on an ancestor of grab_window. + ++ Or if grab_type is GrabtypeTouchBegin or GrabtypeTouchBeginInert, a ++ touch grab (see section 4.4) begins if: ++ - a touch begins in grab_window or one of its ancestors, and ++ - the specified modifier keys are down ++ Ownership of the touch sequence is granted to the grabbing client if: ++ - grab_type is not GrabtypeTouchBeginInert, and ++ - a TouchBegin, TouchBeginInert, or pointer passive grab with the same ++ modifier set does not exist on an ancestor of grab_window, or all ++ applicable grabs have released ownership. ++ + A modifier of GrabAnyModifier is equivalent to issuing the request for + all possible modifier combinations (including no modifiers). A client + may request a grab for GrabAnyModifier and explicit modifier +@@ -1097,6 +1372,9 @@ are required to be 0. + A GrabtypeEnter or GrabtypeFocusIn grab is released when the + pointer or focus leaves the window and all of its descendants, + independent of the state of modifier keys. ++ A GrabtypeTouchBegin or GrabtypeTouchBeginInert grab is released when ++ the touch sequence ends, or a client uses XIAllowTouchEvents to reject ++ the touch and remove itself from the touch delivery sequence. + Note that the logical state of a device (as seen by means of the + protocol) may lag the physical state if device event processing is + frozen. +@@ -1109,10 +1387,11 @@ are required to be 0. + with the same button or keycode and modifier combination, the + failed modifier combinations is returned in modifiers_return. If some + other client already has issued an XIPassiveGrabDevice request of +- grab_type XIGrabtypeEnter or XIGrabtypeFocusIn with the same +- grab_window and the same modifier combination, the failed modifier +- combinations are returned in modifiers_return. If num_modifiers_return +- is zero, all passive grabs have been successful. ++ grab_type XIGrabtypeEnter, XIGrabtypeFocusIn, XIGrabtypeTouchBegin, or ++ XIGrabtypeTouchBeginInert with the same grab_window and the same ++ modifier combination, the failed modifier combinations are returned ++ in modifiers_return. If num_modifiers_return is zero, all passive ++ grabs have been successful. + + If a button grab or enter grab activates, EnterNotify and LeaveNotify + events with mode Grab are generated as if the pointer were to suddenly +@@ -1133,6 +1412,11 @@ are required to be 0. + XIPassiveUngrabNotify are generated and sent to the grabbing client + before the grab deactivates. + ++ See section 4.4 for additional notes on touch grabs, as they do not ++ behave like traditional grabs: in particular, they do not freeze the ++ device, and delivery of touch events continues even if the device is ++ frozen due to a grab by another client. ++ + ┌─── + XIPassiveUngrabDevice + deviceid: DEVICEID +@@ -1149,7 +1433,8 @@ are required to be 0. + The device to establish the passive grab on. + detail + The button number or key symbol to ungrab. +- Must be 0 for GrabtypeEnter and GrabtypeFocusIn. ++ Must be 0 for GrabtypeEnter, GrabtypeFocusIn, and ++ GrabtypeTouchBegin. + grab_type + The type of grab to establish. + grab_window +@@ -1308,6 +1593,44 @@ are required to be 0. + deleted from the device, and a XIPropertyNotify event is generated on + the device. + ++ ┌─── ++ XIAllowTouchEvents: (since XI 2.1) ++ deviceid: DEVICEID ++ touchid: CARD32 ++ event_mode: ALLOWTOUCHMODE ++ flags: SETofALLOWTOUCHFLAGS ++ └─── ++ ++ ALLOWTOUCHMODE { TouchOwnerAccept, TouchOwnerRejectEnd, ++ TouchOwnerRejectContinue } ++ ALLOWTOUCHFLAGS (none currently defined) ++ ++ The XIAllowTouchEvents request allows the current owner of a touch ++ sequence to direct further delivery. ++ ++ deviceid ++ The slave device ID for a grabbed touch sequence. ++ touchid ++ The ID of the touch sequence to modify. ++ event_mode ++ Given TouchOwnerAccept, the client is deemed to have taken control ++ of the touch sequence; TouchEnd events will be sent to all other ++ clients listening to the touch sequence, and they will no longer ++ receive any TouchUpdate events. ++ Given TouchOwnerRejectEnd, the client is no longer interested in the ++ touch sequence, and will receive a TouchEnd event; ownership will be ++ passed on to the next listener. ++ Given TouchOwnerRejectContinue, the client is not interested in ++ ownership, but still wishes to receive TouchUpdate events; ++ ownership will be passed on to the next listener. ++ flags ++ A bitmask of applicable flags. ++ ++ A BadValue error occurs if the touch ID is invalid, or BadAccess if this ++ client is not the current owner of the specified touch ID. BadValue errors ++ also occur if an invalid value is given for event_mode. Any flags not ++ understood by the server will be ignored. ++ + + 8. Events: + +@@ -1338,6 +1661,12 @@ Version 2.0: + FocusIn + FocusOut + PropertyEvent ++Version 2.1: ++ TouchBegin ++ TouchUpdate ++ TouchUpdateUnowned ++ TouchOwnership ++ TouchEnd + + All events have a set of common fields specified as EVENTHEADER. + +@@ -1481,15 +1810,19 @@ EVENTHEADER { type: + + DEVICEEVENTFLAGS (all events): none + DEVICEEVENTFLAGS (key events only): { KeyRepeat } +- DEVICEEVENTFLAGS (pointer events only): none ++ DEVICEEVENTFLAGS (pointer and touch events only): { PointerEmulated } ++ DEVICEEVENTFLAGS (touch events only): { TouchPendingEnd } + + 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 + press or a key release. The event type may be one of KeyPress, + KeyRelease, ButtonPress, ButtonRelease, Motion. + ++ XI 2.1: The event type may also be TouchBegin, TouchUpdate, ++ TouchUpdateUnowned, or TouchEnd. ++ + detail +- The button number or key code, or 0. ++ The button number, key code, touch ID, or 0. + root + event + child +@@ -1517,8 +1850,12 @@ EVENTHEADER { type: + Button state before the event. + valuators + Bitmask of valuators provided in axisvalues. ++ XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and ++ TouchEnd, the valuators are those specified as TouchAxisClass. + axisvalues + Valuator data in device-native resolution. ++ XI 2.1: For event types TouchBegin, TouchUpdate, TouchUpdateUnowned, and ++ TouchEnd, the valuators are those specified as TouchAxisClass. + flags + Miscellaneous information about this event; the union of the + common flag set and either the key or pointer flag set, +@@ -1526,6 +1863,20 @@ EVENTHEADER { type: + KeyRepeat means that this event is for repeating purposes, and + the physical state of the key has not changed. This is only + valid for KeyPress events. ++ PointerEmulated means that this event is an emulated pointer event ++ caused by a touch device. A client listening to touch events and pointer ++ events should ignore PointerEmulated events to avoid duplicate ++ processing. This is only valid for pointer events (MotionNotify, ++ ButtonPress, ButtonRelease). ++ 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 ++ accepted or passed on ownership. The touch will not generate any ++ further motion events once an event with TouchPendingEnd has been ++ received. + + Modifier state in mods is detailed as follows: + base_mods +@@ -1543,6 +1894,27 @@ EVENTHEADER { type: + locked_group + XKB locked group state. + ++ XI 2.1: ++ ++ A TouchBegin event is generated whenever a new touch sequence initializes ++ A TouchEnd event is generated whenever a touch sequence ceases. A ++ TouchUpdate event is generated whenever a touch axis valuator value ++ changes, or a flag (e.g. pending end) has changed for that touch sequence; ++ this may result in a TouchUpdate event being sent with zero valuators. A ++ TouchOwnership event is sent when a client becomes the owner of a touch. ++ ++ The average finger size is significantly larger than one pixel. The ++ selection of the hotspot of a touchpoint is implementation dependent and ++ may not be the logical center of the touch. ++ ++ Touch tracking IDs are provided in the detail field of touch events. Its ++ value is always provided in every touch event. Tracking IDs are ++ represented as unsigned 32-bit values and increase in value for each new ++ touch, wrapping back to 0 upon reaching the numerical limit of IDs. IDs are ++ unique per each slave touch device. ++ ++ Touch events do not generate enter/leave events. ++ + ┌─── + RawEvent + EVENTHEADER +@@ -1673,5 +2045,107 @@ EVENTHEADER { type: + what + Specifies what has been changed. + ++XI 2.1: ++ ++ ┌─── ++ TouchOwnershipEvent (since XI 2.1): ++ EVENTHEADER ++ sourceid: DEVICEID ++ touchid: CARD32 ++ flags: SETofTOUCHOWNERSHIPFLAGS ++ └─── ++ ++ TOUCHOWNERSHIPFLAGS: (none currently defined) ++ ++ A TouchOwnershipEvent indicates that ownership has changed, and the client ++ is now the owner of the touch sequence specified by touchid. ++ ++ sourceid ++ The source device that originally generated the event. ++ touchid ++ The identifier of the touch sequence. ++ flags ++ A bitmask of flags for this event. ++ + + ❧❧❧❧❧❧❧❧❧❧❧ ++ ++ ++Appendix A: XI 2.1 Use-cases ++ ++All use-cases that include the receiving and processing of touch events ++require the client to announce XI 2.1 support in the XIQueryVersion request. ++ ++∙ Client C wants to process touch events from a device D on window W. ++ ⊳ C calls XISelectEvent for ++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W. ++ ⊳ C receives TouchBegin whenever a touch sequence starts within ++ W's borders. ++ ⊳ C receives a TouchOwnership event indicating that it is now the owner ++ of the touch sequence. ++ ⊳ C receives TouchUpdate events whenever a touch axis valuator value ++ changes for a touch sequence it received a TouchBegin event for. ++ ⊳ C receives TouchEnd whenever a touch it received an TouchBegin event ++ for ceases. ++ ++∙ Client C wants to process touch events from a device D on window W, while ++ client I wants to pre-process these events. ++ ⊳ C calls XISelectEvent for ++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W. ++ ⊳ I calls XIPassiveGrab for ++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on a parent ++ window of W. ++ ⊳ I receives TouchBegin whenever a touch begins within window W, as well ++ as a TouchOwnership event indicating that it currently owns the touch ++ sequence. C receives a TouchBegin event as well, but without ++ TouchOwnership. ++ ⊳ When a touch axis valuator changes in this touch sequence, I receives a ++ TouchUpdate event, while C receives a TouchUpdateUnowned event. I may ++ process the events to determine if it is going to claim or reject the ++ touch, whereas C may perform reversible processing. ++ ⊳ If I decides it is going to claim the event for its exclusive ++ processing, it calls XIAllowTouchEvents with the XITouchOwnerAccept flag ++ set; at this point, C receives a TouchEnd event with the ++ TouchAccepted flag set, and undoes any processing it may have done ++ on the touch sequence. Further TouchUpdate events are delivered only ++ to I. ++ ⊳ Alternately, if I decides it does not want to receive further events from ++ this touch sequence, it calls XIAllowTouchEvents with the ++ XITouchOwnerReject flag set; at this point, I receives a TouchEnd event ++ confirming that it has rejected the touch. C receives a TouchOwnership ++ event confirming that it is now the new owner of the touch, and further ++ TouchUpdate events are delivered only to C. As C now owns the touch, ++ it is free to perform irreversible processing of the sequence. ++ ⊳ When the touch physically ceases, a TouchEnd event is sent to all ++ clients still receiving TouchUpdate events. ++ ++∙ Client C wants to process touch events from a device D on window W, while ++ client I wants to process pointer events on window Y, which is W's parent. ++ ⊳ I calls XIPassiveGrab for XI_{ButtonPress,MotionNotify,ButtonRelease} ++ from D on Y. ++ ⊳ C calls XISelectEvent for ++ XI_Touch{Begin|Update|UpdateUnowned|Ownership|End} from D on W. ++ ⊳ I receives a ButtonPress event whenever a touch begins within W, and is ++ considered the owner of the event. C receives a TouchBegin event, but ++ does not receive a TouchOwnership event. ++ ⊳ When the touchpoint moves, I will receive a MotionNotify event, and C ++ will receive a TouchUpdateUnowned event. Event delivery to I will be ++ subject to the standard delivery mechanism (including being queued if ++ the device is frozen, et al), while C receives events as soon as they ++ are processed by the server. ++ ⊳ I may assert ownership by calling XIAllowEvents on Y with AsyncDevice, ++ which will cause all further events to be sent only to I, with a ++ TouchEnd event being sent to C. ++ ⊳ Alternately, I may assert disinterest by calling XIAllowEvents on Y ++ with ReplayDevice, which will cause no further events from that touch ++ to be sent to I, and a TouchOwnership event to be sent to C, with ++ subsequent motion events being sent as TouchMotion. ++ ++∙ Driver DRV provides touch support from tracked device D: ++ ⊳ DRV initializes a TouchClass for the device and a TouchAxisClass for ++ each axis available on the device. ++ ⊳ DRV parses D's device protocol and selects one touch sequence to be ++ emulated as pointer event. ++ ⊳ DRV calls the respective input driver API with the touch sequence ++ data. The touch sequence emulating a pointer has the respective flag ++ set. DRV does not submit pointer data for any touchpoint. +--- a/XIproto.txt ++++ b/XIproto.txt +@@ -1650,7 +1650,7 @@ + feedback class BellFeedback, which is reported in the + BellFeedbackState structure. The members of that structure are: + +- CLASS String: ++ CLASS Bell: + [class: CARD8 + length: CARD16 + feedback id: CARD8 +@@ -1676,7 +1676,7 @@ + class Led, which is reported in the LedFeedbackState structure. + The members of that structure are: + +- CLASS String: ++ CLASS Led: + [class: CARD8 + length: CARD16 + feedback id: CARD8 +@@ -1781,7 +1781,7 @@ + feedback id: CARD8 + int_to_display: INT32] + +- Some devices are capable of displaying an string. This is done ++ Some devices are capable of displaying a string. This is done + using feedback class StringFeedbackClass using the + StringFeedbackCtl structure. The members of that structure are + as follows: +@@ -1978,29 +1978,19 @@ Controlling Device Encoding + A server can impose restrictions on how modifiers can be + changed (for example, if certain keys do not generate up + transitions in hardware or if multiple keys per modifier are +- not supported). The status reply is Failed if some such +- restriction is violated, and none of the modifiers are changed. ++ not supported). If some such restriction is violated, the status ++ reply is MappingFailed, and none of the modifiers are changed. + +- If the new non-zero keycodes specified for a modifier differ +- from those currently defined, and any (current or new) keys for +- that modifier are logically in the down state, then the status +- reply is Busy, and none of the modifiers are changed. ++ If the new keycodes specified for a modifier differ from those ++ currently defined and any (current or new) keys for that ++ modifier are in the logically down state, the status reply is ++ MappingBusy, and none of the modifiers are changed. + + This request generates a DeviceMappingNotify event on a Success + status. The DeviceMappingNotify event will be sent only to + those clients that have expressed an interest in receiving that + event via the XSelectExtensionEvent request. + +- A X server can impose restrictions on how modifiers can be +- changed, for example, if certain keys do not generate up +- transitions in hardware or if multiple modifier keys are not +- supported. If some such restriction is violated, the status +- reply is MappingFailed , and none of the modifiers are changed. +- If the new keycodes specified for a modifier differ from those +- currently defined and any (current or new) keys for that +- modifier are in the logically down state, the status reply is +- MappingBusy, and none of the modifiers are changed. +- + 2.20 Controlling Button Mapping + + These requests are analogous to the core GetPointerMapping and +@@ -2350,7 +2340,7 @@ Controlling Device Encoding + specified device and window. Events generated by SetDeviceFocus + when the device is not grabbed have mode Normal. Events + generated by SetDeviceFocus when the device is grabbed have +- mode WhileGrabbed. Events generated when a device grab actives ++ mode WhileGrabbed. Events generated when a device grab activates + have mode Grab, and events generated when a device grab + deactivates have mode Ungrab. + diff --git a/x11-proto/inputproto/files/inputproto-2.0.2-xi2.1.patch b/x11-proto/inputproto/files/inputproto-2.0.2-xi2.1.patch new file mode 100644 index 0000000..2f07fab --- /dev/null +++ b/x11-proto/inputproto/files/inputproto-2.0.2-xi2.1.patch @@ -0,0 +1,191 @@ +--- a/XI2.h ++++ b/XI2.h +@@ -32,10 +32,12 @@ + #define Dont_Check 0 + #endif + #define XInput_2_0 7 ++#define XInput_2_1 8 + + + #define XI_2_Major 2 + #define XI_2_Minor 0 ++#define XI_2_1_Minor 1 + + /* Property event flags */ + #define XIPropertyDeleted 0 +@@ -65,6 +67,8 @@ + #define XIGrabtypeKeycode 1 + #define XIGrabtypeEnter 2 + #define XIGrabtypeFocusIn 3 ++#define XIGrabtypeTouchBegin 4 ++#define XIGrabtypeTouchBeginInert 5 + + /* Passive grab modifier */ + #define XIAnyModifier (1U << 31) +@@ -79,6 +83,11 @@ + #define XIAsyncPair 4 + #define XISyncPair 5 + ++/* XIAllowTouchEvents bitmask event-modes */ ++#define XITouchOwnerAccept (1 << 0) ++#define XITouchOwnerRejectEnd (1 << 1) ++#define XITouchOwnerRejectContinue (1 << 2) ++ + /* DeviceChangedEvent change reasons */ + #define XISlaveSwitch 1 + #define XIDeviceChange 2 +@@ -113,15 +122,27 @@ + #define XISlaveKeyboard 4 + #define XIFloatingSlave 5 + +-/* Device classes */ ++/* Device classes: classes that are not identical to Xi 1.x classes must be ++ * numbered starting from 8. */ + #define XIKeyClass 0 + #define XIButtonClass 1 + #define XIValuatorClass 2 ++#define XITouchClass 8 ++#define XITouchValuatorClass 9 + + /* Device event flags (common) */ + /* Device event flags (key events only) */ + #define XIKeyRepeat (1 << 16) +-/* Device event flags (pointer events only) */ ++/* Device event flags (pointer and touch events only) */ ++#define XIPointerEmulated (1 << 16) ++/* Device event flags (touch events only) */ ++#define XITouchPendingEnd (1 << 17) ++ ++/* Touch modes */ ++#define XIDirectTouch 1 ++#define XIDependentTouch 2 ++#define XIIndependentPointer 3 ++#define XISemiMultitouch 4 + + /* XI2 event mask macros */ + #define XISetMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] |= (1 << ((event) & 7))) +@@ -151,7 +172,12 @@ + #define XI_RawButtonPress 15 + #define XI_RawButtonRelease 16 + #define XI_RawMotion 17 +-#define XI_LASTEVENT XI_RawMotion ++#define XI_TouchBegin 18 ++#define XI_TouchEnd 19 ++#define XI_TouchOwnership 20 ++#define XI_TouchUpdate 21 ++#define XI_TouchUpdateUnowned 22 ++#define XI_LASTEVENT XI_TouchUpdateUnowned + /* NOTE: XI2LASTEVENT in xserver/include/inputstr.h must be the same value + * as XI_LASTEVENT if the server is supposed to handle masks etc. for this + * type of event. */ +@@ -177,5 +203,10 @@ + #define XI_RawButtonPressMask (1 << XI_RawButtonPress) + #define XI_RawButtonReleaseMask (1 << XI_RawButtonRelease) + #define XI_RawMotionMask (1 << XI_RawMotion) ++#define XI_TouchBeginMask (1 << XI_TouchBegin) ++#define XI_TouchEndMask (1 << XI_TouchEnd) ++#define XI_TouchOwnershipChangedMask (1 << XI_TouchOwnershipChanged) ++#define XI_TouchUpdateMask (1 << XI_TouchUpdate) ++#define XI_TouchUpdateUnownedMask (1 << XI_TouchUpdateUnowned) + + #endif /* _XI2_H_ */ +--- a/XI2proto.h.ori/XI2proto.h 2011-06-07 06:14:26.000000000 +0200 ++++ b/XI2proto.h 2011-06-19 17:39:44.085856683 +0200 +@@ -92,9 +92,10 @@ + #define X_XIDeleteProperty 58 + #define X_XIGetProperty 59 + #define X_XIGetSelectedEvents 60 ++#define X_XIAllowTouchEvents 61 + + /** Number of XI requests */ +-#define XI2REQUESTS (X_XIGetSelectedEvents - X_XIQueryPointer + 1) ++#define XI2REQUESTS (X_XIAllowTouchEvents - X_XIQueryPointer + 1) + /** Number of XI2 events */ + #define XI2EVENTS (XI_LASTEVENT + 1) + +@@ -188,6 +189,32 @@ + uint16_t pad2; + } xXIValuatorInfo; + ++/** ++ * Denotes multitouch capability on a device. ++ */ ++typedef struct { ++ uint16_t type; /**< Always TouchClass */ ++ uint16_t length; /**< Length in 4 byte units */ ++ uint16_t sourceid; /**< source device for this class */ ++ uint8_t mode; /**< DirectTouch or DependentTouch */ ++ uint8_t num_touches; /**< Maximum number of touches (0==unlimited) */ ++} xXITouchInfo; ++ ++/** ++ * Denotes a multitouch valuator capability on a device. ++ * One XITouchValuatorInfo describes exactly one valuator (axis) on the device. ++ */ ++typedef struct { ++ uint16_t type; /**< Always TouchValuatorClass */ ++ uint16_t length; /**< Length in 4 byte units */ ++ uint16_t sourceid; /**< source device for this class */ ++ uint16_t number; /**< Valuator number */ ++ Atom label; /**< Axis label */ ++ FP3232 min; /**< Min value */ ++ FP3232 max; /**< Max value */ ++ uint32_t resolution; /**< Resolutions in units/m */ ++} xXITouchValuatorInfo; ++ + + /** + * Used to select for events on a given window. +@@ -772,6 +799,22 @@ + } xXIGetPropertyReply; + #define sz_xXIGetPropertyReply 32 + ++/** ++ * Accept or reject a grabbed touch sequence. ++ */ ++typedef struct { ++ uint8_t reqType; ++ uint8_t ReqType; /**< Always ::X_XIAllowTouchEvents */ ++ uint16_t length; /**< Length in 4 byte units */ ++ uint32_t touchid; ++ uint16_t deviceid; ++ uint8_t mode; /**< bitmask */ ++ uint8_t pad; ++} xXIAllowTouchEventsReq; ++#define sz_xXIAllowTouchEventsReq 12 ++ ++ ++ + /************************************************************************************* + * * + * EVENTS * +@@ -857,7 +900,28 @@ + } xXIDeviceChangedEvent; + + /** +- * Default input event for pointer or keyboard input. ++ * The owner of a touch stream has passed on ownership to another client. ++ */ ++typedef struct ++{ ++ uint8_t type; /**< Always GenericEvent */ ++ uint8_t extension; /**< XI extension offset */ ++ uint16_t sequenceNumber; ++ uint32_t length; /**< Length in 4 byte units */ ++ uint16_t evtype; /**< XI_TouchOwnership */ ++ uint16_t deviceid; /**< Device that has changed */ ++ Time time; ++ uint16_t sourceid; /**< Source of the new classes */ ++ uint16_t pad0; ++ uint32_t touchid; ++ uint32_t flags; ++ uint32_t pad1; ++ uint32_t pad2; ++} xXITouchOwnershipEvent; ++ ++/** ++ * Default input event for pointer, keyboard or touch input. ++ + */ + typedef struct + { diff --git a/x11-proto/inputproto/inputproto-2.0.1-r1.ebuild b/x11-proto/inputproto/inputproto-2.0.1-r1.ebuild new file mode 100644 index 0000000..4d17451 --- /dev/null +++ b/x11-proto/inputproto/inputproto-2.0.1-r1.ebuild @@ -0,0 +1,30 @@ +# Copyright 1999-2011 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 +# $Header: /var/cvsroot/gentoo-x86/x11-proto/inputproto/inputproto-2.0.1.ebuild,v 1.8 2011/03/15 21:12:16 xarthisius Exp $ + +EAPI=3 + +XORG_EAUTORECONF=yes +inherit xorg-2 + +DESCRIPTION="X.Org Input protocol headers" + +KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86 ~ppc-aix ~x86-fbsd ~x64-freebsd ~x86-freebsd ~ia64-hpux ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" +IUSE="utouch" + +RDEPEND="" +DEPEND="${RDEPEND} +!<x11-libs/libXi-1.2.99" + + +src_prepare() { + if use utouch ; then + epatch "${FILESDIR}/${PN}-2.0.1-xi2.1.patch" + fi + xorg-2_src_prepare +} + +src_install() { + xorg-2_src_install +} + diff --git a/x11-proto/inputproto/inputproto-2.0.2-r1.ebuild b/x11-proto/inputproto/inputproto-2.0.2-r1.ebuild new file mode 100644 index 0000000..db04ad9 --- /dev/null +++ b/x11-proto/inputproto/inputproto-2.0.2-r1.ebuild @@ -0,0 +1,27 @@ +# Copyright 1999-2011 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 +# $Header: /var/cvsroot/gentoo-x86/x11-proto/inputproto/inputproto-2.0.2.ebuild,v 1.1 2011/06/08 21:57:31 chithanh Exp $ + +EAPI=4 +inherit xorg-2 + +DESCRIPTION="X.Org Input protocol headers" + +KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~ppc-aix ~x86-fbsd ~x64-freebsd ~x86-freebsd ~ia64-hpux ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" +IUSE="utouch" + +RDEPEND="" +DEPEND="${RDEPEND} +!<x11-libs/libXi-1.2.99" + +src_prepare() { + if use utouch ; then + epatch "${FILESDIR}/${PN}-2.0.2-xi2.1.patch" + fi + xorg-2_src_prepare +} + +src_install() { + xorg-2_src_install +} + |