[PATCH] fixesproto v6: Pointer barrier thresholds

Thu May 3 16:46:47 PDT 2012

On Thu, 2012-05-03 at 16:35 +1000, Peter Hutterer wrote:
> 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)

Just the perpendicular movement seems to have been enough for Unity, but
you're right; the client could probably make better decisions with both axes.

> 
> 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.
> 

The client already gets the accelerated data via the velocity field.
Also, since the accelerated data is scaled by the framebuffer size I
found (at least with touchpads) that the barrier behaviour changed
noticeably depending on the layout of my screen(s). This felt odd,
especially since, while the events were being sent, the barrier was
blocking the motion anyway.

A generic event won't have the same annoying size limitation as a
regular event, so we might as well send both raw and cooked data for
both axes, and the delta-t.

Unless you think it should be sending either raw or cooked, but not
both?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120504/1e41141e/attachment.pgp>