[PATCH] fixesproto v6: Pointer barrier thresholds

Peter Hutterer peter.hutterer at who-t.net
Wed May 2 23:35:38 PDT 2012


On Thu, May 03, 2012 at 12:40:58PM +1000, Christopher James Halse Rogers wrote:
> On Thu, 2012-05-03 at 11:05 +1000, Peter Hutterer wrote:
> > On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers wrote:
> > > ---
> > > 
> > > I've got a corresponding xserver patch, but it needs updating for the
> > > Great Reindent of '12.  Might as well get support for the protocol additions 
> > > before fixing it up.
> > > 
> > > A slightly different variant of this (it's gone through a number of iterations
> > > in conjunction with the Unity team) is used by the Unity shell as infrastructure
> > > for the one-launcher-per-display support, so there's evidence that it's a usable
> > > protocol.
> > 
> > looks good, a few minor clarifications are needed below. The main change I'd
> > like to see is a change to use generic events instead of a standard event..
> 
> I'll finish reading up on how to make that happen, then :)
> 
> > 
> > we've hit the maximum event number in the past, adding another non-generic
> > event can cause us to stretch over the limit.
> > http://lists.x.org/archives/xorg-devel/2010-March/006716.html
> > 
> > >  configure.ac   |    2 +-
> > >  fixesproto.txt |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  xfixesproto.h  |   59 +++++++++++++++++++++++++++++++++++
> > >  xfixeswire.h   |   23 +++++++++++--
> > >  4 files changed, 173 insertions(+), 5 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..6f8c705 100644
> > > --- a/fixesproto.txt
> > > +++ b/fixesproto.txt
> > > @@ -650,6 +650,100 @@ 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}
> > > +	BarrierEventID:			CARD32
> > > +
> > > +13.2 Events
> > > +
> > > +BarrierNotify
> > > +
> > > +		subtype:		BarrierEvent
> > > +		window:			WINDOW
> > > +		event-id:		BarrierEventID
> > > +		barrier:		BARRIER
> > > +		velocity:		CARD32
> > > +		x, y:			INT16
> > > +		raw-displacement:	FP1616
> > > +		delta-t:		INT16
> > > +		deviceid:		INT16
> > > +
> > > +13.3 Requests
> > > +
> > > +SelectBarrierInput
> > > +
> > > +		window:			WINDOW
> > > +		event-mask:		SETofBarrierEvent
> > > +
> > > +
> > > +	This request directs barrier events to the named window.  Subtype
> > > +	indicates the trigger of the event, which is Hit when the barrier has
> > > +	prevented pointer movement and ThresholdExceeded when the barrier has
> > > +	been hit but has not prevented pointer movement due to the threshold
> > > +	being exceeded.
> > > +	
> > > +	Barrier is the barrier on which the event was triggered. (x,y) contain
> > > +	the coordinates of the pointer after restriction by any	applicable
> > > +	barriers, and velocity is the unrestricted instantaneous velocity
> > > +	of the pointer, perpendicular to the barrier.
> > 
> > how is velocity defined?
> > (edit: found it below, this should be either in some common section or
> > everywhere. You could just define a VELOCITY type and explain it there)
> 
> That makes sense, I'll do so.
> 
> > 
> > > +
> > > +	deviceid is the identifier of the device which caused the barrier
> > > +	event, raw-displacement and delta-t are the raw valuator (purpendicular
> > 
> > I'm not sure what you raw-displacement here is, can you clarify? 
> > 
> 
> Raw-displacement is exactly the value you'd get if you were subscribed
> to XI 2 raw events and selected the valuator perpendicular to the
> barrier.
> 
> It (and delta-t) are here so that a client can get a pre-acceleration
> idea of the velocity and user behaviour if the client desires.  This is
> useful for clients to determine when they want to release the barrier.

Two questions:
Is this really enough then? don't you need x and y to determine that?
Compare a movement of -10/0 against a vertical barrier with a movement of
-10/-70. The former is almost certainly trying to push through, the latter
is almost certainly trying to move north, but wobbling a bit.
(also, raw event data is in FP3232, iirc)

second - is the raw driver data enough? isn't the accelerated data of more
interest since it maps much more against what the user is trying to do?
I have no clue what data the driver submits, but I have a rough feeling of
how much the mouse will move when I do.

> > s/valuator/valuators
> > typo: purpendicular
> > 
> And I thought I'd spell-checked it.  Oops :).
> 
> > > +	to the barrier) and time-since-last-input-event for deviceid
> > > +	respectively.
> > > +
> > > +	event-id is an identifier for this barrier event. A barrier event
> > > +	begins when the pointer is first restricted by the barrier, and ends
> > > +	with the first mouse event that is not restricted by the barrier.
> > 
> > event-id is unique per-device? per-server? per-something?
> > I assume the second, given that device id isn't required to release the
> > pointer, might be worth pointing out.
> 
> Unique per-barrier per-server, modulo wrap around. I'll make this
> clearer.
> 
> > 
> > > +
> > > +	In the case of multiple overlapping barriers an event is sent for each.
> > > +
> > > +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 block the pointer if the threshold
> > > +	velocity is exceeded. The velocity is measured in px/sec perpendicular
> > > +	to the barrier.  
> > 
> > should state that px/sec is after acceleration is applied (i suspect that's
> > the case) just to make sure that's clear
> 
> Yup.
> 
> > 
> > > +
> > > +	Once the pointer has been stopped by the barrier it will remain blocked
> > > +	for the duration of the barrier event.
> > > +	
> > > +	Errors: IDChoice, Window, Value, Device
> > > +
> > > +BarrierReleasePointer
> > > +
> > > +		barrier:		BARRIER
> > > +		event-id:		BarrierEventID
> > > +
> > > +	Temporarily allow the pointer to pass through a pointer barrier.
> > > +	This disables the barrier for as long as event-id is valid - that is,
> > > +	as long as the pointer remains in contact with the barrier.
> > > +
> > > +	Requests to release the pointer for an event-id which is not current
> > > +	are silently ignored.
> > > +
> > > +	Errors: Barrier
> > > +
> > > +
> > 
> > is there a need for this to take a number of event-ids?
> > corner-case, certainly, I admit.
> 
> Hm.  Given that I've earlier said that in the case of multiple
> overlapping barriers an event is sent for each, this might indeed be
> necessary.
> 
> To properly support multiple overlapping barriers I think there'd need
> to be changes elsewhere.  Specifically, if a single pointer event is
> blocked by multiple barriers the server sends out an event for each
> barrier, but the client has no way of knowing whether that's a response
> to a single pointer movement or not.
> 
> This could easily be supported by adding an extra field to the
> BarrierEvent for the number of subsequent events triggered by the same
> pointer event.
> 
> I'm not sure if this is worth doing.

if you use GenericEvents you have space and you can pack all Barriers hit by
a single pointer movement into the same event.

> 
> > 
> > >  99. Future compatibility
> > >  
> > >  This extension is not expected to remain fixed.  Future changes will
> > > diff --git a/xfixesproto.h b/xfixesproto.h
> > > index fcf409a..4e2d3d6 100644
> > > --- a/xfixesproto.h
> > > +++ b/xfixesproto.h
> > > @@ -532,6 +532,65 @@ typedef struct {
> > >  
> > >  #define sz_xXFixesDestroyPointerBarrierReq 8
> > >  
> > > +/*************** Version 6.0 ******************/
> > > +
> > > +#define BarrierEventID CARD32
> > > +
> > > +typedef struct {
> > > +  CARD8   type;
> > > +  CARD8   subtype;
> > > +  CARD16  sequenceNumber B16;
> > > +  Window  window; B32;
> > > +  BarrierEventID event_id B32;
> > > +  Barrier barrier;
> > > +  CARD32  velocity B32;
> > > +  INT16   x B16;
> > > +  INT16   y B16;
> > > +  CARD32  raw_displacement B32;
> > > +  CARD16  delta_t B16;  
> > > +  CARD16  deviceid B16;
> > > +} xXFixesBarrierNotifyEvent;
> > 
> > see generic event comment
> > 
> > > +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
> > 
> > it'd be great to shoehorn this into the existing request but I suspect that
> > has a potential to break things. so reluctantly ack
> 
> It'd be a SMOP to have the server/libxfixes use a different request
> based on whether or not both sides support fixes v6, but that would be
> an extra piece to get wrong.

yeah, and nasty. I suspect we have enough requests left in xfixes to not
worry about this yet :)

Cheers,
  Peter

> > > +
> > > +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;
> > > +    Barrier barrier B32;
> > > +    BarrierEventID event_id B32;
> > > +} xXFixesBarrierReleasePointerReq;
> > > +
> > > +#define sz_xXFixesBarrierReleasePointerReq	12
> > > +
> > > +#undef BarrierEventID
> > >  #undef Barrier
> > >  #undef Region
> > >  #undef Picture
> > > diff --git a/xfixeswire.h b/xfixeswire.h
> > > index 432349a..0230595 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
> > > @@ -111,8 +115,6 @@
> > >  
> > >  #define XFixesDisplayCursorNotifyMask	    (1L << 0)
> > >  
> > > -#define XFixesNumberEvents		    (2)
> > > -
> > >  /* errors */
> > >  #define BadRegion			    0
> > >  #define BadBarrier			    1
> > > @@ -136,4 +138,17 @@
> > >  #define BarrierNegativeX		    (1L << 2)
> > >  #define BarrierNegativeY		    (1L << 3)
> > >  
> > > +/*************** Version 6 ******************/
> > > +
> > > +#define XFixesBarrierNotify                 2
> > > +
> > > +#define XFixesBarrierHitNotify			0
> > > +#define XFixesBarrierThresholdExceededNotify	1
> > > +
> > > +#define XFixesBarrierHitNotifyMask			(1L << 0)
> > > +#define XFixesBarrierThresholdExceededNotifyMask	(1L << 1)
> > > +
> > > +#define XFixesNumberEvents		    (XFixesBarrierNotify+1)
> > > +
> > > +
> > >  #endif	/* _XFIXESWIRE_H_ */
> > > -- 
> > > 1.7.9.1
> >  
> > _______________________________________________
> > xorg-devel at lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 
> 




More information about the xorg-devel mailing list