[PATCH] fixesproto v6: Pointer barrier thresholds

Peter Hutterer peter.hutterer at who-t.net
Thu May 3 21:08:31 PDT 2012 

On Fri, May 04, 2012 at 09:46:47AM +1000, Christopher James Halse Rogers wrote:
> 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.

I'm confused. velocity is pixels/s, right? that doesn't necessarily
translate into the raw events or the accelerated data.

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

that's a bug, need to fix this one day.

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

both, might as well.

Cheers,
  Peter

More information about the xorg-devel mailing list