[PATCH] fixesproto v6: Pointer barrier thresholds
Christopher James Halse Rogers
christopher.halse.rogers at canonical.com
Wed May 2 19:40:58 PDT 2012
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.
> 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.
>
> > 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.
>
> 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
-------------- 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/20120503/602c0517/attachment.pgp>
More information about the xorg-devel
mailing list