[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