Implement pressure barriers and releases (server, try 1)

[Jasper St. Pierre]

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.


> >     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.

- 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.

Cheers,
>    Peter
>

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20121124/7a404776/attachment.html>