Implement pressure barriers and releases (server, try 1)
Jasper St. Pierre
jstpierre at mecheye.net
Sat Nov 24 20:31:36 PST 2012
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
> > xiproto  and libXi  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
> 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
> emulation for example). but if you set your mind to 1.15 now, you get
> 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
> > 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  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
> "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)
> 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
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
> > 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
> 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
- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg-devel