[PATCH x11proto-fixes (v2)] fixesproto v6: Pointer barrier thresholds

Peter Hutterer peter.hutterer at who-t.net
Mon Jun 11 23:14:52 PDT 2012


sorry about the lag

On Mon, May 21, 2012 at 04:18:49PM +1000, Christopher James Halse Rogers wrote:
> v2: Use a GenericEvent for BarrierNotify
>     Add PointerReleased event type
>     Clarify scope of barrier event-id
>     Release multiple barriers in a single ReleasePointer call.
> ---
>  configure.ac   |    2 +-
>  fixesproto.txt |  132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  xfixesproto.h  |   64 +++++++++++++++++++++++++++
>  xfixeswire.h   |   20 ++++++++-
>  4 files changed, 214 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f85b802..07dd29a 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -22,7 +22,7 @@ dnl
>  dnl Process this file with autoconf to create configure.
>  
>  AC_PREREQ([2.60])
> -AC_INIT([FixesProto], [5.0],
> +AC_INIT([FixesProto], [6.0],
>          [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
>  AM_INIT_AUTOMAKE([foreign dist-bzip2])
>  AM_MAINTAINER_MODE
> diff --git a/fixesproto.txt b/fixesproto.txt
> index 5903ac9..6035f1d 100644
> --- a/fixesproto.txt
> +++ b/fixesproto.txt
> @@ -1,5 +1,5 @@
>                          The XFIXES Extension
> -			    Version 5.0
> +			    Version 6.0
>  			 Document Revision 1
>  			     2010-11-15
>  			    Keith Packard
> @@ -650,6 +650,136 @@ DestroyPointerBarrier
>  
>  	Errors: Barrier 
>  
> +************* XFIXES VERSION 6 OR BETTER ***********
> +
> +13. Pointer Barriers Expansion
> +
> +This update extends pointer barriers to optionally allow the pointer through
> +when a threshold is reached.  This can be useful for desktop environments that
> +wish to use a large region of the screen, such as an entire edge, to provide a
> +casual target while allowing determined movement to pass through.
> +
> +13.1 Types
> +
> +	BarrierEvent:			{Hit, ThresholdExceeded, PointerReleased}
> +	BarrierEventID:			CARD32
> +	BarrierEventDetails:		{ barrier:	BARRIER,
> +					  type:		BarrierEvent,
> +					  event-id:	BarrierEventID }
> +
> +13.2 Events
> +
> +BarrierNotify
> +
> +		type:			BYTE
> +		extension:		CARD8
> +		sequenceNumber:		CARD16
> +		length:			CARD32
> +		evtype:			CARD16
> +		window:			WINDOW
> +		x, y:			INT16
> +		dx, dy:			FP3232
> +		raw-dx, raw-dy:		FP3232
> +		dt:			INT16
> +		deviceid:		DEVICEID
> +		details:		LISTofBarrierEventDetails

you'll need an extra field to list how many details there are. In the core
protocol, these are generally determined by the size of the request/reply
but to keep those extendable I prefer to have a separate field that lists
the number of elements.
[edit: now that I see the header file, it's there in the struct, should be
listed here separately though]

> +
> +	BarrierNotify uses the X Generic Event extension.  Type is thus always
> +	GenericEvent (35), extension is the major opcode of this extension,
> +	sequenceNumber is the low 16 bits of the request sequence number,
> +	length is how much bigger than 32 bytes the event is, in units of 
> +	4 bytes. Evtype is the type of this event, which is always
> +	BarrierNotify (0).
> +
> +	(x, y) contain the coordinates of the pointer after restriction by
> +	any applicable barriers or server-side clamping (such as to screen
> +	edges).
> +
> +	(dx, dy) and (raw-dx, raw-dy) are the valuators for the input event
> +	which caused the BarrierNotify to be emitted, before any clamping
> +	(such as to the screen edge, or by a barrier) is applied.
> +	(dx, dy) are the values after acceleration, (raw-dx, raw-dy) are the
> +	raw values before any acceleration is applied. dt is the server time
> +	in milliseconds since the last input event, and deviceid is the id of
> +	the input device which triggered the barrier.
> +
> +	Each item in the details list contains the information for a barrier
> +	triggered by this input event. If there are multiple overlapping
> +	barriers blocking pointer motion each one will be represented in
> +	this list.
> +
> +	barrier is the ID of the barrier hit.
> +
> +	Type indicates the trigger of the event:
> +	 Hit when the barrier has prevented pointer movement.
> +	 ThresholdExceeded when the barrier has been hit but has not
> +	prevented pointer movement due to the threshold being exceeded.
> +	 PointerReleased when the barrier would have blocked motion but
> +	has been rendered permeable by a BarrierReleasePointer request.
> +
> +	event-id is an identifier for this barrier event. A barrier event
> +	begins when the pointer is first restricted by the barrier and remains
> +	valid until the first input event from deviceid which is not
> +	restricted by the barrier. The event-id is unique per-barrier.
> +
> +	Since a barrier event is associated with a deviceid there can be more
> +	than one event active for a given barrier simultaneously.
> +
> +
> +13.3 Requests
> +
> +SelectBarrierInput
> +
> +		window:			WINDOW
> +		event-mask:		SETofBarrierEvent
> +
> +	This request directs barrier events to the named window.

that is weird. why not send the events to the client that issued the
request? what happens when the window becomes unviewable and how is this
window related to the drawable in the CreatePointerBarrier request?

> +
> +CreatePointerBarrierVelocity
> +
> +		barrier:		    BARRIER
> +		drawable:		    DRAWABLE
> +		x1, y2, x2, y2:		    INT16
> +		directions:		    CARD32
> +		velocity:		    CARD32
> +		devices:		    LISTofDEVICEID
> +
> +	Creates a pointer barrier along the line specified by the given
> +	coordinates on the screen associated with the given drawable. This
> +	has identical semantics to CreatePointerBarrier, except that the
> +	barrier created will not initially block the pointer if the threshold
> +	velocity is exceeded. The velocity is measured in px/sec perpendicular
> +	to the barrier.  
> +
> +	Once the pointer has been stopped by the barrier it will remain blocked
> +	for the duration of the barrier event unless released by a
> +	BarrierReleasePointer request.

missing: 

A pointer hitting the barrier results in a BarrierNotify event.

(should be added to the CreatePointerBarrier blurb too)

> +	
> +	Errors: IDChoice, Window, Value, Device
> +
> +BarrierReleasePointer
> +
> +		barriers:		LISTof{ BARRIER, 
> +						BarrierEventID}
> +
> +	Temporarily allow the pointer to pass through a set of pointer
> +	barriers. For each barrier in barriers this allows the pointer to pass
> +	through for as long as the corresponding event-id is valid.
> +
> +	A single barrier may appear in barriers more than once with a
> +	different associated event-id each time. In this way a client can
> +	release a barrier for multiple input devices in one request.
> +
> +	If a requested event-id is not current for its associated barrier
> +	then that, and only that, part of the request is silently ignored.
> +
> +	If the same (barrier, event-id) pair appears more than once in
> +	barriers then the request behaves as if that pair appeared exactly
> +	once.
> +
> +	Errors: Barrier
> +
> +
>  99. Future compatibility
>  
>  This extension is not expected to remain fixed.  Future changes will
> diff --git a/xfixesproto.h b/xfixesproto.h
> index fcf409a..bb1949b 100644
> --- a/xfixesproto.h
> +++ b/xfixesproto.h
> @@ -532,6 +532,70 @@ typedef struct {
>  
>  #define sz_xXFixesDestroyPointerBarrierReq 8
>  
> +/*************** Version 6.0 ******************/
> +
> +#define BarrierEventID CARD32
> +
> +typedef struct
> +{
> +    CARD8     type;                   /* Always GenericEvent */
> +    CARD8     extension;              /* XFIXES extension offset */
> +    CARD16    sequenceNumber;
> +    CARD32    length;                 /* Length in 4 byte units */
> +    CARD16    evtype;                 /* Always BarrierNotify  */
> +    WINDOW    window;
> +    INT16     x;
> +    INT16     y;
> +    FP3232    dx;
> +    FP3232    dy;
> +    FP3232    raw-dx;
> +    FP3232    raw-dy;
> +    INT16     dt;
> +    INT16     deviceid;
> +    INT16     num_eventdetails;
> +    /* Array of BarrierEventDetails */
> +} xXFixesBarrierNotifyEvent;

you need to shuffle this around so everything is 4-byte aligned. moving
deviceid after evtype would do the job here. Don't forget the B32, B16 stuff
here too.

BarrierEventDetails should have a struct too.

> +
> +typedef struct {
> +    CARD8   reqType;
> +    CARD8   xfixesReqType;
> +    CARD16  length B16;
> +    Barrier barrier B32;
> +    Window  window B32;
> +    INT16   x1 B16;
> +    INT16   y1 B16;
> +    INT16   x2 B16;
> +    INT16   y2 B16;
> +    CARD32  directions;
> +    CARD32  velocity;
> +    CARD16  pad B16;
> +    CARD16  num_devices B16;
> +    /* array of CARD16 devices */
> +} xXFixesCreatePointerBarrierVelocityReq;
> +
> +#define sz_xXFixesCreatePointerBarrierVelocityReq 32
> +
> +typedef struct {
> +    CARD8   reqType;
> +    CARD8   xfixesReqType;
> +    CARD16  length B16;
> +    Window  window B32;
> +    CARD32  eventMask B32;
> +} xXFixesSelectBarrierInputReq;
> +
> +#define sz_xXFixesSelectBarrierInputReq	12
> +
> +typedef struct {
> +    CARD8   reqType;
> +    CARD8   xfixesReqType;
> +    CARD16  length B16;
> +    CARD16  num_barriers;
> +    /* array of BARRIER, BarrierEventID */
> +} xXFixesBarrierReleasePointerReq;

I'd prefer some struct here again.

rest looks good, thanks for the updates.

Cheers,
  Peter

> +
> +#define sz_xXFixesBarrierReleasePointerReq	6
> +
> +#undef BarrierEventID
>  #undef Barrier
>  #undef Region
>  #undef Picture
> diff --git a/xfixeswire.h b/xfixeswire.h
> index 432349a..e3a23c7 100644
> --- a/xfixeswire.h
> +++ b/xfixeswire.h
> @@ -48,7 +48,7 @@
>  #define _XFIXESWIRE_H_
>  
>  #define XFIXES_NAME	"XFIXES"
> -#define XFIXES_MAJOR	5
> +#define XFIXES_MAJOR	6
>  #define XFIXES_MINOR	0
>  
>  /*************** Version 1 ******************/
> @@ -89,8 +89,12 @@
>  /*************** Version 5 ******************/
>  #define X_XFixesCreatePointerBarrier	    31
>  #define X_XFixesDestroyPointerBarrier	    32
> +/*************** Version 6 ******************/
> +#define X_XFixesCreatePointerBarrierVelocity 33
> +#define X_XFixesSelectBarrierInput          34
> +#define X_XFixesBarrierReleasePointer       35
>  
> -#define XFixesNumberRequests		    (X_XFixesDestroyPointerBarrier+1)
> +#define XFixesNumberRequests		    (X_XFixesBarrierReleasePointer+1)
>  
>  /* Selection events share one event number */
>  #define XFixesSelectionNotify		    0
> @@ -136,4 +140,16 @@
>  #define BarrierNegativeX		    (1L << 2)
>  #define BarrierNegativeY		    (1L << 3)
>  
> +/*************** Version 6 ******************/
> +
> +#define XFixesBarrierNotify                 0
> +
> +#define XFixesBarrierHitNotify			0
> +#define XFixesBarrierThresholdExceededNotify	1
> +#define XFixesBarrierPointerReleasedNotify	2
> +
> +#define XFixesBarrierHitNotifyMask			(1L << 0)
> +#define XFixesBarrierThresholdExceededNotifyMask	(1L << 1)
> +#define XFixesBarrierPointerReleasedNotifyMask		(1L << 2)
> +
>  #endif	/* _XFIXESWIRE_H_ */
> -- 
> 1.7.10



More information about the xorg-devel mailing list