Implement pressure barriers and releases (server, try 1)

[Peter Hutterer]

On Tue, Nov 20, 2012 at 02:50:40PM -0500, Jasper St. Pierre wrote:
> 
> This is a heavy modification of RAOF's patch set that's used in Ubuntu
> for Unity and was was once proposed here. This implements the server side:
> xiproto [1] and libXi [2] patches are boring and bland, and read as you
> pretty much expect. If there isn't too much turbulence with this current
> patch set, I'll go and attach them here for a more formal review of
> those. I'd like to get this in for 1.14, and I understand this is sort of
> a tight schedule.

I don't want to make any promises here, but I suspect this is more likely to
land for 1.15. Over the last couple of releases we've merged features that
were decidedly incomplete (touch, smooth scrolling, as two examples) and
fixing them up under time pressure has not been useful. So this one I want
to actually get done and tested before we merge it.

1.14 may still be possible if it turns out to be easier and we have enough
test cases to assume that it's not broken out of the box (like touch pointer
emulation for example). but if you set your mind to 1.15 now, you get spared
the disappointment later :)
 
> There are a few limitations and issues with the current patch set, but
> hopefully these can live as-is for now, fixing up the implementation
> later.
> 
>   Limitations:
> 
>     1. Barriers on screen edges will not get events, due to
>        unintended interactions between RANDR and barriers. Multiple
>        solutions have been discussed on #xorg-devel, but none of them
>        are easy and convenient to fix. This is an extension of bug
>        #48008 [3] in some ways.

this is something that we should consider fixing, as it makes the corner
hotspot use-case easier to clients.

>     2. Overlapping barriers will not work: only one will receive
>        events. This is an extreme edge case, considering that
>        window managers are supposed to be the intended user of
>        barriers, and that they control their own destiny.

this should be explicitly clarified in the protocol. something along these
lines:
"pointer motion is blocked at the closest barrier blocking in the given
direction. If two or more barriers block on the same coordinates, the first
barrier is considered blocking.
Barrier events are only sent to the one blocking barrier (if applicable) for
the current direction"

Bonus points for making it really predictable, e.g. oldest barrier wins
(which, given that we have a list of barriers, should be easy enough)

which brings the next point - should barriers be assigned to windows, where
useful?

>     3. Releasing a barrier will lose pointer acceleration across
>        the barrier. Unity's current use case includes releasing
>        a barrier when the pointer is at high velocity, so it may
>        be worth re-introducing a "velocity barrier", which is only
>        solid at speeds less than some threshold.

this is honestly something that I'd like to have tested reasonably well in
real-world situations before merging. it's all nice if we can push through,
but if the end result is confusing pointer motion, we need to find a better
solution.

>     4. The interaction with grabs hasn't been decided yet; as with
>        existing barriers, a pointer grab will still allow barriers
>        to constrain the cursor. Currently, an event is sent to the
>        appropriate client when a barrier is hit, always, even when
>        a different client has a grab on the pointer. Semantics can
>        and probably should be tweaked here.

this is a can of worms that we really need to sort out before we merge
anything because I suspect this can make or break the whole approach.

- if you're sending events while a grab is active, can the non-grabbing
  client release the pointer from the barrier?
- if not, what's the point of sending the event in the first place? is there
  one? (honestly not sure here, we don't send enter/leave events either
  during grabs iirc)
- if you're sending events during grabs but the client cannot release, how
  will the client know that the device is grabbed? destroying the barrier
  may be a use-case in response to hitting it but the client needs to know
  if a grab is active here.
- if you're _not_ sending events while a grab is active, the UI experience
  is inconsistent. a grab is always activated on button press, so if you're
  planning to drag and drop something but you hit a barrier on the way -
  what's the behaviour there?

the last point also feeds in with point 1, where we could and should use
barriers for corner hotspot.

one more thing I found when testing the first patch you sent (the wobbly
cursor one): how likely is it that a user sticks to the barrier until a
release request arrives? I find that even when I try really hard to move
right only along the barrier, I tend to get the odd x-1 event. which would
generate a new event_id, thus trigger a new block/release cycle.
do you have any data on that yet?

Cheers,
   Peter