On Tue, Sep 10, 2019 at 09:49:51PM +0200, Michael Weiser wrote:
> Hello,
>
> I've written a small X client that detects when the pointer hits a
> screen edge in order to trigger actions based on where the edge was hit
> - the classic hot corner use case. The trigger for doing this yet again
> was that all the tools I looked at either polled the pointer position or
> subscribed to all pointer motion which irked me on an aesthetic level. ;)
>
> I've now placed non-constraining pointer barriers at all screen edges
> using Xfixes and get notified through XInput2 when the pointer hits them
> which seems very efficient to me and works quite well. I've noticed a
> couple of things though:
>
> 1. Since barriers have a 2px hit box[1] I thought I could nicely use the
> XI_BarrierHit event to detect that the user had activated a hot corner
> or edge and XI_BarrierLeave to learn when the pointer moved away again.
> Since I didn't want to risk any interference with normal user experience
> and only wanted to get notified anyway I made the barriers
> non-constraining. This however meant that I got a leave event for every
> hit even though the pointer was pushing at the very edge of the screen
> not going anywhere.
>
> Moving the pointer very slowly it can be seen that first there is a hit
> event event for the initial hit but then pushing onwards off-screen
> produces a leave as if the pointer actually moved beyond the barrier and
> out of the hit box even though continually hitting the screen edge. It
> snapping back from off-screen then seems to produce another hit event.
>
> This can be reproduced by changing the interactive demo[2] to place the
> barrier at the very top or bottom of the screen.
This sounds like a bug but possibly technically correct at the same time.
Arguably, the leave event shouldn't be produced here though but you are
technically pushing through the barrier, it just happens that the cursor is
"warped" to a different position.
There may be a way to fix the specs and define all these but I suspect the
easy way out here would be to define a screen-edge barrier as a constraining
one.
> It also happens with a constraining barrier anywhere on the screen when
> approaching it along a screen edge (i.e. as if trying to sneak around it
> off-screen and being caught :).
>
> 2. Moving the barrier away from the screen edge to then track its
> crossing and somehow devise whether it was an entry or departure I found
> that for non-constraining barriers, I'm not reliably getting events for
> every crossing of the barrier. Neither pointer speed nor input device
> (trackpad, mouse) seem to be a factor - for some crossings I just get no
> event. This also happens with the interactive demo[2] after making the
> barrier non-constraining and deactivating the release code.
Most likely a bug, possibly caused by bad calculation of the crossing lines.
> 3. Making a barrier that starts at a screen edge constraining and then
> releasing the pointer immediately after receiving the barrier hit event
> shows another peculiar behaviour: When moving the pointer against the
> barrier along that screen edge so that it continually tries to push
> off-screen makes it get stuck at the barrier *while* barrier hit events
> keep coming in and being released. It seems as if the release is getting
> lost on the way. This can be reproduced with the interactive demo[2].
As i read this, at least this one seems to be correct based on [1]:
"A pointer that moves against a barrier, pushes against it for 3 more events
and then pulls back will thus generate 4 XI_BarrierHit events and one
XI_BarrierLeave event."
> As said above I've worked around this to my satisfaction but am still
> wondering if those behaviours are to be expected or indeed bugs in any
> participant of the interaction (my brain being the prime suspect :).
>
> And finally any advice on whether pointer barriers are a good choice for
> the hot corner use case in the first place would be highly welcome.
yes, that's literally what they were designed for :) Alas, this was 7 years
ago so any memory has been well and truly paged out by now.
Cheers,
Peter
>
> [1] https://who-t.blogspot.com/2012/12/whats-new-in-xi-23-pointer-barrier.html
> [2]
> http://people.freedesktop.org/~whot/xi2-recipes/pointer-barriers-interactive.c
> --
> Thanks,
> Michael
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
