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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
