On Tue, 10 Sep 2019 21:49:51 +0200 Michael Weiser <mich...@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@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 - ras...@rasterman.com _______________________________________________ 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