Implement pressure barriers and releases (server, try 1)

[Peter Hutterer]

On Sat, Nov 24, 2012 at 11:31:36PM -0500, Jasper St. Pierre wrote:
> On Thu, Nov 22, 2012 at 10:02 PM, Peter Hutterer
> <peter.hutterer at who-t.net>wrote:
> 
> > 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 :)
> >
> 
> Noted, but GNOME would like to have this for 3.6, so 1.14 would be
> extremely wonderful. I'll try the best I can to work on appropriate test
> cases. I'm having fun writing them -- good work on xorg-integration-tests
> and xorg-gtest!
> 
> 
> > > 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.
> >
> >
> It's something that's extremely difficult to fix. One of the recommended
> solutions was to implement monitor edges in terms of barriers, but this is
> a big change in semantics. The ASCII art on the bug spells it well -- right
> now, as far as I'm aware, the ability to cut corners like that is a feature.
> 
> The hacky-but-might-just-work solution is to recognize barriers that are
> touching monitor edges and extend them automatically downwards to the
> bottom of the screen for clients. I've been wondering myself if defining a
> new barriers API in terms of monitor corners and edges might be worth it.
> 
> If you have any other ideas, I'd be more than happy to try them out.

I think the following should be doable:
- in the server, handle barriers before screen edges
- tell clients that if they want hotspots to work, they need 
  keep track of RandR events and rearrange the barriers as required
- tell clients to set up barriers larger than the screen dimensions to avoid
  bug 48008, and/or
- define a BarrierInfinity that's a valid coordinate for barriers so the
  server treats the barrier as infinite.

> > >     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?
> >
> 
> I'm not sure about this. This seems to be a quality-of-implementation
> issue, and I can't ever imagine it coming up in the real world. While never
> likely, I'd like for someone to be able to add this ability in the future
> if they desire.
> 
> >     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)
> 
> 
> GNOME's use case is wanting a "pressure barrier" -- if you press hard
> enough against a barrier, things happen. We don't want to release barriers,
> but simply use the dx/dy values to build up pressure, and Do A Thing when
> the pressure passes some threshold. I think that this should happen during
> drag-and-drop as well. I think of pointer barriers right now as ways to
> extend Fitts's Law in cases where the desktop environment knows more about
> how it is laid out than Xorg, so I think that barriers being dropped during
> pointer grabs makes as much sense as not doing RANDR clamping during
> pointer grabs.

make sense. so let's agree on pointer barriers are active during a device
grab, events are sent to the barrier-client, and a relase will trigger a
release.

i.e. grabs are irrelevant for barriers and their events.

> - 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?
> >
> 
> I noticed it in testing, but wasn't sure how widespread it was, or whether
> it was local to my touchpad / driver / configuration / distribution / etc.
> 
> When giving these patches to other people to try out, they've encountered
> the same issues.
> 
> I still don't know if it's a Synaptics bug or not, but for now, I've added
> a 2px "hit box" on either side of the barrier that won't reset the event
> that gives a bit of wiggle room for this bit of bouncing pointer.

having tested that with your little test app I can say that it works quite
fine and the loss of pointer accel at crossing the barrier is not really
noticable.

Cheers,
   Peter