Questions on pointer barrier behaviour

Tue Sep 10 21:25:01 UTC 2019

On Tue, 10 Sep 2019 21:49:51 +0200 Michael Weiser <michael at weiser.dinsnail.net>
said:

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

you know the ancient trick is just to place input only windows along all the
screen edges and listen for mouse enter/leave events... :) (override-redirect
ones). catch - wm's do this too (enlightenment does) so you may fight with the
wm's own windows on these screen edges... :)

so 1 pixel wide or high window ... for 4 windows along the edges of each
screen. :) requires no extensions to so this. the won't suffer any of your
below issues as the cor pointer will always be trapped/stopped ad a screen
boundary :)

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

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com