Re: Questions on pointer barrier behaviour
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
Re: Questions on pointer barrier behaviour
On Tue, 10 Sep 2019 21:49:51 +0200 Michael Weiser 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
Questions on pointer barrier behaviour
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. 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
Pointer Barrier
Hi allI am new here and hopefully you can help me with my problem. Ive send this mail once, not sure if it got lost or no one could help me so I try again :D. I am trying to useXFixesCreatePointerBarrier and XFixesDestroyPointerBarrierCreating works and I can see how the barrier works. To release the barrier I can catch the events usingXI_BarrierHitXI_BarrierLeavewhich I did and after receiving that event I used XIBarrierReleasePointer to release it. I know if I wanna disable this barrier the step has to be repeated everytime the pointer hits the barrier etc.What I like to do is to destroy the barrier so that it should not be used at all. I like to remove it completely. UsingXFixesDestroyPointerBarrier on the barrier gives me after couple of eventsX Error of failed request: 141 Major opcode of failed request: 138 (XFIXES) Minor opcode of failed request: 32 () Serial number of failed request: 87 Current serial number in output stream: 87What is it I am doing wrong? Hope someone can help me with that.Cengiz (yaakuro) ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Pointer Barrier
Hi allI am new here and hopefully you can help me with my problem. I am trying to useXFixesCreatePointerBarrier and XFixesDestroyPointerBarrierCreating works and I can see how the barrier works. To release the barrier I can catch the events usingXI_BarrierHitXI_BarrierLeavewhich I did and after receiving that event I used XIBarrierReleasePointer to release it. I know if I wanna disable this barrier the step has to be repeated everytime the pointer hits the barrier etc.What I like to do is to destroy the barrier so that it should not be used at all. I like to remove it completely. UsingXFixesDestroyPointerBarrier on the barrier gives me after couple of eventsX Error of failed request: 141 Major opcode of failed request: 138 (XFIXES) Minor opcode of failed request: 32 () Serial number of failed request: 87 Current serial number in output stream: 87What is it I am doing wrong? Hope someone can help me with that.Cengiz (yaakuro) ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [PULL updated] pointer barrier events/releases (XI2.3)
Peter Hutterer peter.hutte...@who-t.net writes: Jasper St. Pierre (14): cursor: Move pointer barrier code over to XI barriers: Don't loop over the server to destroy a barrier barriers: Switch to an explicit hook for barrier constrainment barriers: Switch to finding the nearest barrier client barriers: Reindent the constrainment hook Add support for XI2.3: Pointer barrier events and releases. barriers: Add support for edge cases when releasing barriers barriers: Add a couple pixels of elbow room for the hit detection barriers: Increment event ID on hit box leave barriers: Send a BarrierLeave event when we leave the hitbox barriers: Clean up code barriers: Send an XI_BarrierLeave event when a barrier is destroyed barriers: Replace complex intersection test with simpler math barriers: Support line and ray barriers Peter Hutterer (18): include: fix comment barriers: Don't allow destroying other client's barriers barriers: Don't allow releasing the pointer on other client's barriers Pass the event list through to the pointer barrier code to return it Xi: fill in barrier root x/y after clamping to RandR outputs dix: skip delivery if it's not the right pointer barrier client dix: handle barrier events properly when converting to core/XI 1.x dix: ignore barrier events in FixUpEventFromWindow Xi: deliver barrier events as grabbed events where necessary Xi: if the device is currently grabbed, flag the barrier event mi: rename mipointer's internal event list Require inputproto 2.2.99.1 tests/xi2: at protocol conversion test for barrier events Xi: swap sequence number and evtype in barrier events Xi: fix swapping for barrier events Xi: fix per-device barrier handling Xi: don't store the window pointer in barriers, store the window ID Xi: if a MD is removed, send a barrier leave event (if applicable) Merged. f793b5f..014a5c8 master - master -- keith.pack...@intel.com pgpnCnF4URKJB.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL updated] pointer barrier events/releases (XI2.3)
Changes to original pull: - added Jasper's rev-by tag to last three commits - removed the XI grab mask commit, this is unrelated to barriers and I'll send it through a different branch The following changes since commit b51a1bd2766e7dc975ca8f1cacc3f8bd0e1a68a3: Merge remote-tracking branch 'whot/for-keith' (2012-11-30 09:31:46 -0800) are available in the git repository at: git://people.freedesktop.org/~whot/xserver barriers for you to fetch changes up to 2eefa5d6e870c57ac6a5930883d8cfe3a3882a43: Xi: if a MD is removed, send a barrier leave event (if applicable) (2012-12-18 08:28:02 +1000) Jasper St. Pierre (14): cursor: Move pointer barrier code over to XI barriers: Don't loop over the server to destroy a barrier barriers: Switch to an explicit hook for barrier constrainment barriers: Switch to finding the nearest barrier client barriers: Reindent the constrainment hook Add support for XI2.3: Pointer barrier events and releases. barriers: Add support for edge cases when releasing barriers barriers: Add a couple pixels of elbow room for the hit detection barriers: Increment event ID on hit box leave barriers: Send a BarrierLeave event when we leave the hitbox barriers: Clean up code barriers: Send an XI_BarrierLeave event when a barrier is destroyed barriers: Replace complex intersection test with simpler math barriers: Support line and ray barriers Peter Hutterer (18): include: fix comment barriers: Don't allow destroying other client's barriers barriers: Don't allow releasing the pointer on other client's barriers Pass the event list through to the pointer barrier code to return it Xi: fill in barrier root x/y after clamping to RandR outputs dix: skip delivery if it's not the right pointer barrier client dix: handle barrier events properly when converting to core/XI 1.x dix: ignore barrier events in FixUpEventFromWindow Xi: deliver barrier events as grabbed events where necessary Xi: if the device is currently grabbed, flag the barrier event mi: rename mipointer's internal event list Require inputproto 2.2.99.1 tests/xi2: at protocol conversion test for barrier events Xi: swap sequence number and evtype in barrier events Xi: fix swapping for barrier events Xi: fix per-device barrier handling Xi: don't store the window pointer in barriers, store the window ID Xi: if a MD is removed, send a barrier leave event (if applicable) Xi/Makefile.am | 2 + Xi/exevents.c| 47 ++ Xi/extinit.c | 41 +- Xi/xibarriers.c | 916 +++ Xi/xibarriers.h | 48 ++ Xi/xichangehierarchy.c | 6 + configure.ac | 2 +- dix/eventconvert.c | 43 ++ dix/events.c | 24 + dix/getevents.c | 15 +- include/events.h | 1 + include/eventstr.h | 24 +- include/input.h | 6 + include/inputstr.h | 2 +- mi/mieq.c| 4 + mi/mipointer.c | 54 ++- mi/mipointer.h | 3 +- test/fixes.c | 26 ++ test/xi2/protocol-eventconvert.c | 216 + xfixes/cursor.c | 432 +- xfixes/xfixes.h | 17 +- 21 files changed, 1465 insertions(+), 464 deletions(-) create mode 100644 Xi/xibarriers.c create mode 100644 Xi/xibarriers.h pgpwqiLJmLebD.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 00/29] Pointer barrier events and barrier releases
n Wed, Dec 12, 2012 at 2:18 AM, Peter Hutterer peter.hutte...@who-t.netwrote: This is the server-side for the pointer-barrier patches, proposed as XI 2.3. It adds events for pointer barriers (when the pointer hits vs leaves the arrier) and the ability to release a pointer across. I hereby propose this for the 1.14 release. Trees for testing available from: git://people.freedesktop.org/~whot/xserver.git barriers git://people.freedesktop.org/~whot/libXi.git barriers git://people.freedesktop.org/~whot/inputproto.git barriers More verbose description: http://who-t.blogspot.com.au/2012/12/whats-new-in-xi-23-pointer-barrier.html KNOWN BROKEN: events/releases in the MPX case, though it works fine if the barrier doesn't apply to more than one device at a time. - releases currently ignore the device id - too many leave events may be sent if a barrier applies to multiple devices I've got patches here that fix this, but they're not quite finished yet. Either way, that's a narrow use-case and it will be fixed before the release. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net Many thanks to Jasper St. Pierre, who did most of the legwork here. And of course Chris Halse-Rogers who started with this feature quite a while ago. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel -- Jasper ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] pointer barrier events/releases (XI2.3)
The following changes since commit b51a1bd2766e7dc975ca8f1cacc3f8bd0e1a68a3: Merge remote-tracking branch 'whot/for-keith' (2012-11-30 09:31:46 -0800) are available in the git repository at: git://people.freedesktop.org/~whot/xserver barriers for you to fetch changes up to 1fe6c2ef09bd7422e20ef7f7f8d38f2d773d842b: Xi: if a MD is removed, send a barrier leave event (if applicable) (2012-12-17 15:04:11 +1000) Jasper St. Pierre (14): cursor: Move pointer barrier code over to XI barriers: Don't loop over the server to destroy a barrier barriers: Switch to an explicit hook for barrier constrainment barriers: Switch to finding the nearest barrier client barriers: Reindent the constrainment hook Add support for XI2.3: Pointer barrier events and releases. barriers: Add support for edge cases when releasing barriers barriers: Add a couple pixels of elbow room for the hit detection barriers: Increment event ID on hit box leave barriers: Send a BarrierLeave event when we leave the hitbox barriers: Clean up code barriers: Send an XI_BarrierLeave event when a barrier is destroyed barriers: Replace complex intersection test with simpler math barriers: Support line and ray barriers Peter Hutterer (19): include: fix comment barriers: Don't allow destroying other client's barriers barriers: Don't allow releasing the pointer on other client's barriers Pass the event list through to the pointer barrier code to return it Xi: fill in barrier root x/y after clamping to RandR outputs dix: skip delivery if it's not the right pointer barrier client dix: handle barrier events properly when converting to core/XI 1.x dix: ignore barrier events in FixUpEventFromWindow Xi: deliver barrier events as grabbed events where necessary Xi: if the device is currently grabbed, flag the barrier event mi: rename mipointer's internal event list Require inputproto 2.2.99.1 tests/xi2: at protocol conversion test for barrier events Xi: swap sequence number and evtype in barrier events Xi: fix swapping for barrier events dix: don't copy the wrong event mask when activating a passive grab Xi: fix per-device barrier handling Xi: don't store the window pointer in barriers, store the window ID Xi: if a MD is removed, send a barrier leave event (if applicable) Xi/Makefile.am | 2 + Xi/exevents.c| 47 ++ Xi/extinit.c | 41 +- Xi/xibarriers.c | 916 +++ Xi/xibarriers.h | 48 ++ Xi/xichangehierarchy.c | 6 + configure.ac | 2 +- dix/eventconvert.c | 43 ++ dix/events.c | 24 + dix/getevents.c | 15 +- dix/grabs.c | 5 +- include/events.h | 1 + include/eventstr.h | 24 +- include/input.h | 6 + include/inputstr.h | 2 +- mi/mieq.c| 4 + mi/mipointer.c | 54 ++- mi/mipointer.h | 3 +- test/fixes.c | 26 ++ test/xi2/protocol-eventconvert.c | 216 + xfixes/cursor.c | 432 +- xfixes/xfixes.h | 17 +- 22 files changed, 1469 insertions(+), 465 deletions(-) create mode 100644 Xi/xibarriers.c create mode 100644 Xi/xibarriers.h pgpmhYAGYtqAB.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 0/3] per-device pointer barrier event handling
These are the promised fixes for pointer-barrier events if there is more than master pointer, plus a fix to avoid accessing recently-freed memory (if a event is sent after a barrier is destroyed) Yesterday's series plus these three should conclude the pointer barrier event/release support. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 00/29] Pointer barrier events and barrier releases
This is the server-side for the pointer-barrier patches, proposed as XI 2.3. It adds events for pointer barriers (when the pointer hits vs leaves the arrier) and the ability to release a pointer across. I hereby propose this for the 1.14 release. Trees for testing available from: git://people.freedesktop.org/~whot/xserver.git barriers git://people.freedesktop.org/~whot/libXi.git barriers git://people.freedesktop.org/~whot/inputproto.git barriers More verbose description: http://who-t.blogspot.com.au/2012/12/whats-new-in-xi-23-pointer-barrier.html KNOWN BROKEN: events/releases in the MPX case, though it works fine if the barrier doesn't apply to more than one device at a time. - releases currently ignore the device id - too many leave events may be sent if a barrier applies to multiple devices I've got patches here that fix this, but they're not quite finished yet. Either way, that's a narrow use-case and it will be fixed before the release. Many thanks to Jasper St. Pierre, who did most of the legwork here. And of course Chris Halse-Rogers who started with this feature quite a while ago. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 01/29] cursor: Move pointer barrier code over to XI
From: Jasper St. Pierre jstpie...@mecheye.net
In order to send events to specific windows associated with the barrier,
we need to move the code that handles barriers to somewhere where it's
easier to construct and send events. Rather than duplicating XSync with
its XSyncSelectAlarm, re-use the existing XI infrastructure.
For now, just move a bunch of code over, rename some things, and initialize
the new structures, but still consider it a separate codebase. Pointer barrier
requests are still handled by XFixes, so this is a weird intermediate state.
It's unknown whether we'll add explicit requests to pointer barriers inside
XI.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
Xi/Makefile.am | 2 +
Xi/extinit.c| 4 +
Xi/xibarriers.c | 548
Xi/xibarriers.h | 47 +
xfixes/cursor.c | 432 +---
xfixes/xfixes.h | 17 +-
6 files changed, 606 insertions(+), 444 deletions(-)
create mode 100644 Xi/xibarriers.c
create mode 100644 Xi/xibarriers.h
diff --git a/Xi/Makefile.am b/Xi/Makefile.am
index 69c7886..af85bd0 100644
--- a/Xi/Makefile.am
+++ b/Xi/Makefile.am
@@ -78,6 +78,8 @@ libXi_la_SOURCES =\
ungrdevk.h \
xiallowev.c \
xiallowev.h \
+ xibarriers.c \
+ xibarriers.h \
xichangecursor.c \
xichangecursor.h \
xichangehierarchy.c \
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 7e30755..1074b23 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -122,6 +122,7 @@ SOFTWARE.
#include xiqueryversion.h
#include xisetclientpointer.h
#include xiwarppointer.h
+#include xibarriers.h
/* Masks for XI events have to be aligned with core event (partially anyway).
* If DeviceButtonMotionMask is != ButtonMotionMask, event delivery
@@ -1263,6 +1264,9 @@ XInputExtensionInit(void)
if (!AddCallback(ClientStateCallback, XIClientCallback, 0))
FatalError(Failed to add callback to XI.\n);
+if (!XIBarrierInit())
+FatalError(Could not initialize barriers.\n);
+
extEntry = AddExtension(INAME, IEVENTS, IERRORS, ProcIDispatch,
SProcIDispatch, IResetProc, StandardMinorOpcode);
if (extEntry) {
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
new file mode 100644
index 000..ba9fd06
--- /dev/null
+++ b/Xi/xibarriers.c
@@ -0,0 +1,548 @@
+/*
+ * Copyright 2012 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright © 2002 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of Keith Packard not be used in
+ * advertising or publicity pertaining to distribution of the software without
+ * specific, written prior permission. Keith Packard makes no
+ * representations about the suitability of this software for any purpose. It
+ * is provided as is without express or implied warranty.
+ *
+ * KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+
+#include xibarriers.h
+#include scrnintstr.h
+#include cursorstr.h
+#include dixevents.h
+#include servermd.h
+#include mipointer.h
+#include inputstr.h
+#include windowstr.h
+#include xace.h
+#include
[PATCH 06/29] Add support for XI2.3: Pointer barrier events and releases.
From: Jasper St. Pierre jstpie...@mecheye.net
This adds support for clients that would like to get a notification
every time a barrier is hit, and allows clients to temporarily release
a barrier so that pointers can go through them, without having to
destroy and recreate barriers.
Based on work by Chris Halse Rogers chris.halse.rog...@canonical.com
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c | 32
Xi/extinit.c | 38 ++-
Xi/xibarriers.c| 107 +
Xi/xibarriers.h| 8 ++--
dix/eventconvert.c | 39 +++
include/events.h | 1 +
include/eventstr.h | 22 +++
include/inputstr.h | 2 +-
mi/mieq.c | 4 ++
9 files changed, 245 insertions(+), 8 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index 2caf98c..e606d9e 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1639,6 +1639,34 @@ ProcessTouchEvent(InternalEvent *ev, DeviceIntPtr dev)
UpdateDeviceState(dev, ev-device_event);
}
+static void
+ProcessBarrierEvent(InternalEvent *e, DeviceIntPtr dev)
+{
+Mask filter;
+WindowPtr pWin;
+BarrierEvent *be = e-barrier_event;
+xEvent *ev;
+int rc;
+
+if (!IsMaster(dev))
+return;
+
+if (dixLookupWindow(pWin, be-window, serverClient, DixReadAccess) !=
Success)
+return;
+
+rc = EventToXI2(e, ev);
+if (rc != Success) {
+ErrorF([Xi] event conversion from %s failed with code %d\n,
__func__, rc);
+return;
+}
+
+filter = GetEventFilter(dev, ev);
+
+DeliverEventsToWindow(dev, pWin, ev, 1,
+ filter, NullGrab);
+free(ev);
+}
+
/**
* Process DeviceEvents and DeviceChangedEvents.
*/
@@ -1788,6 +1816,10 @@ ProcessOtherEvent(InternalEvent *ev, DeviceIntPtr device)
case ET_TouchEnd:
ProcessTouchEvent(ev, device);
break;
+case ET_BarrierHit:
+case ET_BarrierLeave:
+ProcessBarrierEvent(ev, device);
+break;
default:
ProcessDeviceEvent(ev, device);
break;
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 1074b23..175d89b 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -252,7 +252,8 @@ static int (*ProcIVector[]) (ClientPtr) = {
ProcXIChangeProperty, /* 57 */
ProcXIDeleteProperty, /* 58 */
ProcXIGetProperty, /* 59 */
-ProcXIGetSelectedEvents /* 60 */
+ProcXIGetSelectedEvents, /* 60 */
+ProcXIBarrierReleasePointer /* 61 */
};
/* For swapped clients */
@@ -317,7 +318,8 @@ static int (*SProcIVector[]) (ClientPtr) = {
SProcXIChangeProperty, /* 57 */
SProcXIDeleteProperty, /* 58 */
SProcXIGetProperty, /* 59 */
-SProcXIGetSelectedEvents/* 60 */
+SProcXIGetSelectedEvents, /* 60 */
+SProcXIBarrierReleasePointer /* 61 */
};
/*
@@ -840,6 +842,33 @@ STouchOwnershipEvent(xXITouchOwnershipEvent * from,
xXITouchOwnershipEvent * to)
swapl(to-child);
}
+static void
+SBarrierEvent(xXIBarrierEvent * from,
+ xXIBarrierEvent * to) {
+to-type = from-type;
+
+cpswapl(from-length, to-length);
+cpswapl(from-time, to-time);
+cpswaps(from-deviceid, to-deviceid);
+cpswaps(from-sourceid, to-sourceid);
+cpswapl(from-event, to-event);
+cpswapl(from-root, to-root);
+cpswapl(from-root_x, to-root_x);
+cpswapl(from-root_y, to-root_y);
+
+#define SWAP_FP3232(x, y) \
+do {\
+cpswapl((x).integral, (y).integral);\
+cpswapl((x).frac, (y).frac);\
+} while(0)
+
+SWAP_FP3232(from-dx, to-dx);
+SWAP_FP3232(from-dy, to-dy);
+cpswapl(from-dtime, to-dtime);
+cpswapl(from-barrier, to-barrier);
+cpswapl(from-eventid, to-eventid);
+}
+
/** Event swapping function for XI2 events. */
void
XI2EventSwap(xGenericEvent *from, xGenericEvent *to)
@@ -886,6 +915,11 @@ XI2EventSwap(xGenericEvent *from, xGenericEvent *to)
case XI_RawTouchEnd:
SRawEvent((xXIRawEvent *) from, (xXIRawEvent *) to);
break;
+case XI_BarrierHit:
+case XI_BarrierLeave:
+SBarrierEvent((xXIBarrierEvent *) from,
+ (xXIBarrierEvent *) to);
+break;
default:
ErrorF([Xi] Unknown event type to swap. This is a bug.\n);
break;
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index 0affde6..f16094d 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -56,6 +56,8 @@
#include xace.h
#include list.h
#include exglobals.h
+#include eventstr.h
+#include mi.h
RESTYPE PointerBarrierType;
@@ -66,11 +68,18 @@ static DevPrivateKeyRec BarrierScreenPrivateKeyRec;
typedef struct PointerBarrierClient *PointerBarrierClientPtr;
struct
[PATCH 17/29] Pass the event list through to the pointer barrier code to return it
Instead of having the pointer barrier code enqueue events separately from
GetPointerEvents, pass the event list through and let it add to it.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/xibarriers.c | 15 ---
dix/getevents.c | 15 +++
include/input.h | 3 ++-
mi/mipointer.c | 6 --
mi/mipointer.h | 3 ++-
5 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index 27b21ee..104280c 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -335,7 +335,8 @@ void
input_constrain_cursor(DeviceIntPtr dev, ScreenPtr screen,
int current_x, int current_y,
int dest_x, int dest_y,
- int *out_x, int *out_y)
+ int *out_x, int *out_y,
+ int *nevents, InternalEvent* events)
{
/* Clamped coordinates here refer to screen edge clamping. */
BarrierScreenPtr cs = GetBarrierScreen(screen);
@@ -356,6 +357,10 @@ input_constrain_cursor(DeviceIntPtr dev, ScreenPtr screen,
.dy = dest_y - current_y,
.root = screen-root-drawable.id,
};
+InternalEvent *barrier_events = events;
+
+if (nevents)
+*nevents = 0;
if (xorg_list_is_empty(cs-barriers) || IsFloating(dev))
goto out;
@@ -402,7 +407,9 @@ input_constrain_cursor(DeviceIntPtr dev, ScreenPtr screen,
ev.window = c-window-drawable.id;
c-last_timestamp = ms;
-mieqEnqueue(dev, (InternalEvent *) ev);
+barrier_events-barrier_event = ev;
+barrier_events++;
+*nevents += 1;
}
xorg_list_for_each_entry(c, cs-barriers, entry) {
@@ -429,7 +436,9 @@ input_constrain_cursor(DeviceIntPtr dev, ScreenPtr screen,
ev.window = c-window-drawable.id;
c-last_timestamp = ms;
-mieqEnqueue(dev, (InternalEvent *) ev);
+barrier_events-barrier_event = ev;
+barrier_events++;
+*nevents += 1;
/* If we've left the hit box, this is the
* start of a new event ID. */
diff --git a/dix/getevents.c b/dix/getevents.c
index fa538d9..3d41e1e 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -916,10 +916,13 @@ scale_to_desktop(DeviceIntPtr dev, ValuatorMask *mask,
* @param[in,out] devy y desktop-wide coordinate in device coordinate system
* @param[in,out] screenx x coordinate in desktop coordinate system
* @param[in,out] screeny y coordinate in desktop coordinate system
+ * @param[out] nevents Number of barrier events added to events
+ * @param[in,out] events List of events barrier events are added to
*/
static ScreenPtr
positionSprite(DeviceIntPtr dev, int mode, ValuatorMask *mask,
- double *devx, double *devy, double *screenx, double *screeny)
+ double *devx, double *devy, double *screenx, double *screeny,
+ int *nevents, InternalEvent* events)
{
ScreenPtr scr = miPointerGetScreen(dev);
double tmpx, tmpy;
@@ -933,7 +936,7 @@ positionSprite(DeviceIntPtr dev, int mode, ValuatorMask
*mask,
/* miPointerSetPosition takes care of crossing screens for us, as well as
* clipping to the current screen. Coordinates returned are in desktop
* coord system */
-scr = miPointerSetPosition(dev, mode, screenx, screeny);
+scr = miPointerSetPosition(dev, mode, screenx, screeny, nevents, events);
/* If we were constrained, rescale x/y from the screen coordinates so
* the device valuators reflect the correct position. For screen
@@ -1319,6 +1322,7 @@ fill_pointer_events(InternalEvent *events, DeviceIntPtr
pDev, int type,
int sx, sy; /* for POINTER_SCREEN */
ValuatorMask mask;
ScreenPtr scr;
+int num_barrier_events = 0;
switch (type) {
case MotionNotify:
@@ -1395,7 +1399,10 @@ fill_pointer_events(InternalEvent *events, DeviceIntPtr
pDev, int type,
}
scr = positionSprite(pDev, (flags POINTER_ABSOLUTE) ? Absolute :
Relative,
- mask, devx, devy, screenx, screeny);
+ mask, devx, devy, screenx, screeny,
+ num_barrier_events, events);
+num_events += num_barrier_events;
+events += num_barrier_events;
/* screenx, screeny are in desktop coordinates,
mask is in device coordinates per-screen (the event data)
@@ -1945,7 +1952,7 @@ GetTouchEvents(InternalEvent *events, DeviceIntPtr dev,
uint32_t ddx_touchid,
scr = scale_to_desktop(dev, mask, devx, devy, screenx, screeny);
if (emulate_pointer)
scr = positionSprite(dev, Absolute, mask,
- devx, devy, screenx, screeny);
+ devx, devy, screenx, screeny, NULL, NULL);
/* see fill_pointer_events for coordinate systems */
if (emulate_pointer)
diff --git a/include/input.h b/include/input.h
index a5d0462..23a20b5 100644
--- a/include/input.h
+++ b/include
[PATCH 19/29] dix: skip delivery if it's not the right pointer barrier client
Only deliver to the client that created the barrier, not to other clients.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/events.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/dix/events.c b/dix/events.c
index 3282ef8..49b8bc5 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -219,6 +219,9 @@ static void CheckVirtualMotion(DeviceIntPtr pDev,
QdEventPtr qe,
static void CheckPhysLimits(DeviceIntPtr pDev, CursorPtr cursor,
Bool generateEvents, Bool confineToScreen,
ScreenPtr pScreen);
+static Bool IsWrongPointerBarrierClient(ClientPtr client,
+DeviceIntPtr dev,
+xEvent *event);
/** Key repeat hack. Do not use but in TryClientEvents */
extern BOOL EventIsKeyRepeat(xEvent *event);
@@ -2076,6 +2079,9 @@ DeliverEventToInputClients(DeviceIntPtr dev, InputClients
* inputclients,
if (IsInterferingGrab(client, dev, events))
continue;
+if (IsWrongPointerBarrierClient(client, dev, events))
+continue;
+
mask = GetEventMask(dev, events, inputclients);
if (XaceHook(XACE_RECEIVE_ACCESS, client, win, events, count))
@@ -6064,3 +6070,19 @@ IsInterferingGrab(ClientPtr client, DeviceIntPtr dev,
xEvent *event)
return FALSE;
}
+
+/* PointerBarrier events are only delivered to the client that created that
+ * barrier */
+static Bool
+IsWrongPointerBarrierClient(ClientPtr client, DeviceIntPtr dev, xEvent *event)
+{
+xXIBarrierEvent *ev = (xXIBarrierEvent*)event;
+
+if (ev-type != GenericEvent || ev-extension != IReqCode)
+return FALSE;
+
+if (ev-evtype != XI_BarrierHit ev-evtype != XI_BarrierLeave)
+return FALSE;
+
+return client-index != CLIENT_ID(ev-barrier);
+}
--
1.8.0.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH inputproto] Add pointer barrier events
/specs/XI2proto.txt
@@ -14,6 +14,7 @@ Authors:
History
---
+- v2.3, December 2012: Pointer barrier events added
- v2.2, March 2012: Multitouch support added
- v2.1, December 2011: new raw event behaviour, smooth scrolling support
added
@@ -57,6 +58,10 @@ Changes in version 2.2
- Multitouch support added
+Changes in version 2.3
+--
+
+- Pointer barrier events added
//❧❧❧
@@ -551,6 +556,54 @@ window set has been reached, the event is delivered:
Emulated pointer events will have the PointerEmulated flag set. A touch
event that emulates pointer events has the TouchEmulatingPointer flag set.
+
+[[barrier-events]]
+Pointer barrier events
+^^
+If a master pointer moves against a pointer barrier blocking movement in
+that pointer's direction, the movement of the pointer is clamped to the x or
+y coordinate of the barrier, whichever applies. For a description of pointer
+barriers and barrier creation and destruction see the XFixes protocol
+specification v 5.0 or later.
+http://cgit.freedesktop.org/xorg/proto/fixesproto/plain/fixesproto.txt
+
+A pointer hitting a blocking barrier creates a new barrier event sequence,
+identified by a unique event ID. A new event ID is assigned when the pointer
+first hits a barrier. Subsequent movements against or along the pointer
+barrier are assigned the same event ID. The event generated by the pointer
+leaving the barrier, or being released by a client request, is the last
+event with this event ID. Any future movements of this device blocked by
+this barrier will be assigned a new event ID.
+
+Pointer barrier events are delivered exclusively to the client that created
+the barrier, and to the window specified in the CreatePointerBarrier
+request (the barrier window). A pointer barrier blocks pointer movement
+regardless of whether its window is mapped and/or viewable. If the pointer
+barrier window is destroyed, the pointer barrier remains blocking but a
+client will not receive further events.
+
+If a device is actively grabbed by a client or a passive grab activated
+for this client, and the pointer moves against a pointer barrier created by
+this client and the grab-window is the barrier window, that client will
+receive pointer barrier events if:
+- owner-events is true or false and the grab's event mask includes
+ pointer barrier events, or
+- owner-events is true and the client has selected for barrier events on the
+ barrier window.
+
+If the grab-window is not the barrier window, the client will receive events
+if:
+- the client has selected for barrier events on the barrier window.
+
+If the barrier is not owned by this client, no barrier events are sent to
+this client. The client owning the barrier will receive events if:
+- the client has pointer barrier events selected on the window associated
+ with the pointer barrier
+
+The BarrierDeviceIsGrabbed flag is set whenever a pointer barrier event is
+generated while the device is actively grabbed by any client or a passive
+grab has activated for this device prior to the event.
+
[[glossary-notations]]
Notations used in this document
---
@@ -1940,6 +1993,48 @@ giving the number of trailing unread bytes in the stored
property. If
delete is True and the bytes_after is zero, the property is also
deleted from the device, and a XIPropertyNotify event is generated on
the device.
+
+[[requests-xi23]]
+Requests introduced in version 2.3
+~~
+
+[[requests-barrierreleasepointer]]
+XIBarrierReleasePointer
+^^^
+┌───
+XIBarrierReleasePointer
+num_items: CARD32
+▶
+data:LISTofBARRIERRELEASEINFO
+└───
+
+BARRIERRELEASEINFO { deviceid: DEVICEID,
+ barrier: Barrier,
+ eventid: CARD32 }
+
+Release a pointer currently blocked by a barrier. In the future, movement of
+this pointer against the barrier will not be blocked.
+
+deviceid
+The device currently being blocked by a barrier
+barrier
+The barrier currently blocking the device
+eventid
+The unique event ID assigned to this barrier event sequence
+
+If the barrier given does not currently block this device, or the eventid
+is invalid, this request does nothing.
+
+Releasing a pointer barrier is only valid during one barrier event sequence,
+and only applies to the next movement of this device against this barrier.
+If the pointer moves away from the barrier following a
+XIBarrierReleasePointer request, the release request is discarded. In the
+future, if the pointer moves against the barrier again, a new eventid is
+assigned and the client must re-issue the XIBarrierReleasePointer request.
+
+If the device is not a master pointer device, a BadDevice error results.
+If the barrier does not name a valid barrier
[RFC/PATCH] Pointer barrier events (XI 2.3)
This is the protocol and client-side for the proposed XI 2.3 extension for pointer barrier events and barrier release requests. This feature adds two things: - if a pointer hits a barrier, events are sent to selected clients - a client may release the pointer, allowing it to pass through the barrier with the next movement. This enables two distinct user-visible features: - hot corners/edges that respond to pushing against them (GNOME3 wants this) - ad-hoc transparent barriers, so that depending on the speed of the pointer the user can move through the barrier (Unity wants this) Potential/current issues: - grab behaviour is different to other events - loss of predictable pointer acceleration across a barrier. In my tests, I have not found this to be noticable - device-specific release has not yet been implemented - one of the passive grab tests currently fails For a full view of the development history plus server and tests see the following repos: git://people.freedesktop.org/~whot/inputproto.git :barriers git://people.freedesktop.org/~whot/libXi.git :barriers git://people.freedesktop.org/~whot/xserver.git :barriers git://people.freedesktop.org/~whot/xorg-integration-tests.git :barriers Many thanks to Jasper and Chris, who did most of the work here. I think this is a valuable addition to 1.14, unless someone can find significant issues with the protocol as it is proposed here. Should we merge this for 1.14, I do reserve the right to disable this feature in the server before the release, unless we have a credible client-side implementation. We've learned the lesson with smooth scrolling that a server-implementation only is not good enough. Comments appreciated. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXi] Add support for pointer barrier events
From: Jasper St. Pierre jstpie...@mecheye.net
Co-authored-by: Peter Hutterer peter.hutte...@who-t.net
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
include/X11/extensions/XInput2.h | 47 +++
man/Makefile.am | 3 ++
man/XIBarrierReleasePointer.txt | 76 +
src/Makefile.am | 3 +-
src/XExtInt.c| 62 ++
src/XIBarrier.c | 81
src/XIint.h | 1 +
7 files changed, 272 insertions(+), 1 deletion(-)
create mode 100644 man/XIBarrierReleasePointer.txt
create mode 100644 src/XIBarrier.c
diff --git a/include/X11/extensions/XInput2.h b/include/X11/extensions/XInput2.h
index 26de695..a746012 100644
--- a/include/X11/extensions/XInput2.h
+++ b/include/X11/extensions/XInput2.h
@@ -169,6 +169,16 @@ typedef struct
int status;
} XIGrabModifiers;
+typedef XID PointerBarrier;
+typedef unsigned int BarrierEventID;
+
+typedef struct
+{
+int deviceid;
+PointerBarrier barrier;
+BarrierEventID eventid;
+} XIBarrierReleasePointerInfo;
+
/**
* Generic XI2 event. All XI2 events have the same header.
*/
@@ -328,6 +338,28 @@ typedef struct {
int flags;
} XITouchOwnershipEvent;
+typedef struct {
+int type; /* GenericEvent */
+unsigned long serial; /* # of last request processed by server */
+Bool send_event; /* true if this came from a SendEvent request
*/
+Display *display; /* Display the event was read from */
+int extension;/* XI extension offset */
+int evtype;
+Time time;
+int deviceid;
+int sourceid;
+Windowevent;
+Windowroot;
+doubleroot_x;
+doubleroot_y;
+doubledx;
+doubledy;
+int dtime;
+int flags;
+PointerBarrier barrier;
+BarrierEventID eventid;
+} XIBarrierEvent;
+
_XFUNCPROTOBEGIN
extern Bool XIQueryPointer(
@@ -603,6 +635,21 @@ XIGetProperty(
unsigned char **data
);
+extern void
+XIBarrierReleasePointers(
+Display*display,
+XIBarrierReleasePointerInfo *barriers,
+int num_barriers
+);
+
+extern void
+XIBarrierReleasePointer(
+Display*display,
+int deviceid,
+PointerBarrier barrier,
+BarrierEventID eventid
+);
+
extern void XIFreeDeviceInfo(XIDeviceInfo *info);
_XFUNCPROTOEND
diff --git a/man/Makefile.am b/man/Makefile.am
index af63952..b92d486 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -25,6 +25,7 @@ libmandir = $(LIB_MAN_DIR)
# Source files for X Input v2 man pages
XI2_txt = \
+ XIBarrierReleasePointer.txt \
XIChangeHierarchy.txt \
XIDefineCursor.txt \
XIGrabButton.txt\
@@ -76,6 +77,7 @@ libman_xml = $(libman_txt:.txt=.xml)
# They are created by the xmlto command when generating man pages from DocBook
# The shadow man page contains a gtroff .so request to include the main man
page
XI2_shadows = \
+ XIBarrierReleasePointers.man\
XIUndefineCursor.man\
XIUngrabButton.man \
XIGrabKeycode.man \
@@ -152,6 +154,7 @@ XIDeleteProperty.man: XIChangeProperty.man
XIUngrabEnter.man XIGrabFocusIn.man XIUngrabFocusIn.man: XIGrabEnter.man
XIGetSelectedEvents.man: XISelectEvents.man
XIFreeDeviceInfo.man: XIQueryDevice.man
+XIBarrierReleasePointers.man: XIBarrierReleasePointer.man
# String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure
# Unable to use __libmansuffix__ as underscores are lost in txt -- xml
conversion
diff --git a/man/XIBarrierReleasePointer.txt b/man/XIBarrierReleasePointer.txt
new file mode 100644
index 000..4fa48fe
--- /dev/null
+++ b/man/XIBarrierReleasePointer.txt
@@ -0,0 +1,76 @@
+XIBARRIERRELEASEPOINTER(libmansuffix)
+=
+
+NAME
+
+
+ XIBarrierReleasePointer, XIBarrierReleasePointers - allow pointer movement
across a pointer barrier
+
+SYNOPSIS
+
+
+ #include X11/extensions/XInput2.h
+
+ int XIBarrierReleasePointer( Display *display,
+int deviceid,
+PointerBarrier barrier,
+BarrierEventID eventid);
+
+ int XIBarrierReleasePointers( Display *display,
+ XIBarrierReleasePointerInfo *barriers,
+ int num_barriers);
+
+ display
+ Specifies
Re: [PATCH 3/5] Add support for XI2.3: Pointer barrier notify events
On Tue, Nov 20, 2012 at 02:50:43PM -0500, Jasper St. Pierre wrote:
From: Jasper St. Pierre jstpie...@mecheye.net
This adds support for clients that would like to get a notification
every time a barrier is released, along with a way to temporarily
release a barrier after it has been hit.
This adds two new events to XI: BarrierHitNotify and
BarrierPointerReleasedNotify.
Based on work by Chris Halse Rogers chris.halse.rog...@canonical.com
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
Xi/exevents.c | 43 ++
Xi/extinit.c | 32 ++
Xi/xibarriers.c| 98
++
Xi/xibarriers.h| 1 +
dix/getevents.c| 4 +-
hw/xfree86/modes/xf86RandR12.c | 4 +-
include/events.h | 1 +
include/eventstr.h | 22 ++
include/inputstr.h | 2 +-
include/protocol-versions.h| 2 +-
include/scrnintstr.h | 2 +-
mi/mieq.c | 3 ++
mi/mipointer.c | 12 --
mi/mipointer.h | 4 +-
randr/randrstr.h | 2 +-
randr/rrcrtc.c | 4 +-
16 files changed, 204 insertions(+), 32 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index 4248b9a..98a2cee 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1649,6 +1649,46 @@ ProcessTouchEvent(InternalEvent *ev, DeviceIntPtr dev)
UpdateDeviceState(dev, ev-device_event);
}
+#define INT_TO_FP3232(x) ((FP3232) { (x), 0 })
+
+static void
+ProcessBarrierEvent(InternalEvent *e, DeviceIntPtr dev)
+{
+Mask filter;
+WindowPtr pWin;
+BarrierEvent *be = e-barrier_event;
+xXIBarrierNotifyEvent ev = {
+.type = GenericEvent,
+.extension = IReqCode,
+.sequenceNumber = 0,
+.length = 9,
+.evtype = be-event_type,
+.window = be-window,
+.deviceid = dev-id,
+.time = be-time,
+.x = be-x,
+.y = be-y,
+.dx = INT_TO_FP3232(be-dx),
+.dy = INT_TO_FP3232(be-dy),
+.raw_dx = INT_TO_FP3232(be-raw_dx),
+.raw_dy = INT_TO_FP3232(be-raw_dy),
+.dt = be-dt,
+.event_id = be-event_id,
+.barrier = be-barrierid,
+};
+
+if (!IsMaster(dev))
+return;
+
+if (dixLookupWindow(pWin, be-window, serverClient, DixReadAccess) !=
Success)
+return;
+
+filter = GetEventFilter(dev, (xEvent *) ev);
+
+DeliverEventsToWindow(dev, pWin, (xEvent *) ev, 1,
+ filter, NullGrab);
+}
+
/**
* Process DeviceEvents and DeviceChangedEvents.
*/
@@ -1798,6 +1838,9 @@ ProcessOtherEvent(InternalEvent *ev, DeviceIntPtr
device)
case ET_TouchEnd:
ProcessTouchEvent(ev, device);
break;
+case ET_BarrierNotify:
+ProcessBarrierEvent(ev, device);
+break;
default:
ProcessDeviceEvent(ev, device);
break;
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 1074b23..6571943 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -840,6 +840,33 @@ STouchOwnershipEvent(xXITouchOwnershipEvent * from,
xXITouchOwnershipEvent * to)
swapl(to-child);
}
+static void
+SBarrierNotifyEvent(xXIBarrierNotifyEvent * from,
+xXIBarrierNotifyEvent * to) {
+to-type = from-type;
+
+cpswaps(from-x, to-x);
+cpswaps(from-y, to-y);
+cpswaps(from-dt, to-dt);
+cpswapl(from-length, to-length);
+cpswapl(from-time, to-time);
+
+cpswaps(from-event_id, to-event_id);
+cpswapl(from-barrier, to-barrier);
+cpswapl(from-window, to-window);
+
+#define SWAP_FP3232(x, y) \
+do {\
+cpswapl((x).integral, (y).integral);\
+cpswapl((x).frac, (y).frac);\
+} while(0)
+
+SWAP_FP3232(from-dx, to-dx);
+SWAP_FP3232(from-dy, to-dy);
+SWAP_FP3232(from-raw_dx, to-raw_dx);
+SWAP_FP3232(from-raw_dy, to-raw_dy);
+}
+
/** Event swapping function for XI2 events. */
void
XI2EventSwap(xGenericEvent *from, xGenericEvent *to)
@@ -886,6 +913,11 @@ XI2EventSwap(xGenericEvent *from, xGenericEvent *to)
case XI_RawTouchEnd:
SRawEvent((xXIRawEvent *) from, (xXIRawEvent *) to);
break;
+case XI_BarrierHitNotify:
+case XI_BarrierPointerReleasedNotify:
+SBarrierNotifyEvent((xXIBarrierNotifyEvent *) from,
+(xXIBarrierNotifyEvent *) to);
+break;
default:
ErrorF([Xi] Unknown event type to swap. This is a bug.\n);
break;
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
index a97db56..9b5f657 100644
--- a/Xi/xibarriers.c
+++ b/Xi/xibarriers.c
@@ -56,6 +56,8 @@
#include xace.h
#include list.h
#include exglobals.h
+#include eventstr.h
[PATCH 2/5] cursor: Move pointer barrier code over to XI
From: Jasper St. Pierre jstpie...@mecheye.net
In order to send events to specific windows associated with the barrier,
we need to move the code that handles barriers to somewhere where it's
easier to construct and send events. Rather than duplicating XSync with
its XSyncSelectAlarm, re-use the existing XI infrastructure.
For now, just move a bunch of code over, rename some things, and initialize
the new structures, but still consider it a separate codebase. Pointer barrier
requests are still handled by XFixes, so this is a weird intermediate state.
It's unknown whether we'll add explicit requests to pointer barriers inside
XI.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
Xi/Makefile.am | 2 +
Xi/extinit.c| 4 +
Xi/xibarriers.c | 548
Xi/xibarriers.h | 47 +
xfixes/cursor.c | 432 +---
xfixes/xfixes.h | 17 +-
6 files changed, 606 insertions(+), 444 deletions(-)
create mode 100644 Xi/xibarriers.c
create mode 100644 Xi/xibarriers.h
diff --git a/Xi/Makefile.am b/Xi/Makefile.am
index 69c7886..af85bd0 100644
--- a/Xi/Makefile.am
+++ b/Xi/Makefile.am
@@ -78,6 +78,8 @@ libXi_la_SOURCES =\
ungrdevk.h \
xiallowev.c \
xiallowev.h \
+ xibarriers.c \
+ xibarriers.h \
xichangecursor.c \
xichangecursor.h \
xichangehierarchy.c \
diff --git a/Xi/extinit.c b/Xi/extinit.c
index 7e30755..1074b23 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -122,6 +122,7 @@ SOFTWARE.
#include xiqueryversion.h
#include xisetclientpointer.h
#include xiwarppointer.h
+#include xibarriers.h
/* Masks for XI events have to be aligned with core event (partially anyway).
* If DeviceButtonMotionMask is != ButtonMotionMask, event delivery
@@ -1263,6 +1264,9 @@ XInputExtensionInit(void)
if (!AddCallback(ClientStateCallback, XIClientCallback, 0))
FatalError(Failed to add callback to XI.\n);
+if (!XIBarrierInit())
+FatalError(Could not initialize barriers.\n);
+
extEntry = AddExtension(INAME, IEVENTS, IERRORS, ProcIDispatch,
SProcIDispatch, IResetProc, StandardMinorOpcode);
if (extEntry) {
diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c
new file mode 100644
index 000..a97db56
--- /dev/null
+++ b/Xi/xibarriers.c
@@ -0,0 +1,548 @@
+/*
+ * Copyright 2012 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright © 2002 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that
+ * copyright notice and this permission notice appear in supporting
+ * documentation, and that the name of Keith Packard not be used in
+ * advertising or publicity pertaining to distribution of the software without
+ * specific, written prior permission. Keith Packard makes no
+ * representations about the suitability of this software for any purpose. It
+ * is provided as is without express or implied warranty.
+ *
+ * KEITH PACKARD DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
+ * PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+
+#include xibarriers.h
+#include scrnintstr.h
+#include cursorstr.h
+#include dixevents.h
+#include servermd.h
+#include mipointer.h
+#include inputstr.h
+#include windowstr.h
+#include xace.h
+#include
Re: [PATCH 3/5] cursor: Clean up pointer barrier creation code a tiny bit
On Sat, Nov 03, 2012 at 06:39:34PM -0400, Jasper St. Pierre wrote:
From: Jasper St. Pierre jstpie...@mecheye.net
This will make it much simpler when we add more error paths to the code
that constructs pointer barrier clients.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
xfixes/cursor.c | 54 ++
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 9d7c0f0..a34f65c 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -1245,28 +1245,34 @@ CursorConstrainCursorHarder(DeviceIntPtr dev,
ScreenPtr screen, int mode,
}
}
-static struct PointerBarrierClient *
+static int
CreatePointerBarrierClient(ScreenPtr screen, ClientPtr client,
- xXFixesCreatePointerBarrierReq * stuff)
+ xXFixesCreatePointerBarrierReq * stuff,
+ PointerBarrierClientPtr *client_out)
{
CursorScreenPtr cs = GetCursorScreen(screen);
struct PointerBarrierClient *ret = malloc(sizeof(*ret));
-if (ret) {
-ret-screen = screen;
-ret-barrier.x1 = min(stuff-x1, stuff-x2);
-ret-barrier.x2 = max(stuff-x1, stuff-x2);
-ret-barrier.y1 = min(stuff-y1, stuff-y2);
-ret-barrier.y2 = max(stuff-y1, stuff-y2);
-ret-barrier.directions = stuff-directions 0x0f;
-if (barrier_is_horizontal(ret-barrier))
-ret-barrier.directions = ~(BarrierPositiveX |
BarrierNegativeX);
-if (barrier_is_vertical(ret-barrier))
-ret-barrier.directions = ~(BarrierPositiveY |
BarrierNegativeY);
-xorg_list_add(ret-entry, cs-barriers);
+*client_out = NULL;
+
+if (!ret) {
+return BadAlloc;
}
-return ret;
+ret-screen = screen;
+ret-barrier.x1 = min(stuff-x1, stuff-x2);
+ret-barrier.x2 = max(stuff-x1, stuff-x2);
+ret-barrier.y1 = min(stuff-y1, stuff-y2);
+ret-barrier.y2 = max(stuff-y1, stuff-y2);
+ret-barrier.directions = stuff-directions 0x0f;
+if (barrier_is_horizontal(ret-barrier))
+ret-barrier.directions = ~(BarrierPositiveX | BarrierNegativeX);
+if (barrier_is_vertical(ret-barrier))
+ret-barrier.directions = ~(BarrierPositiveY | BarrierNegativeY);
+xorg_list_add(ret-entry, cs-barriers);
+
+*client_out = ret;
+return Success;
}
int
@@ -1279,7 +1285,7 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
REQUEST(xXFixesCreatePointerBarrierReq);
-REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq,
pad_to_int32(stuff-num_devices));
+REQUEST_SIZE_MATCH(xXFixesCreatePointerBarrierReq);
did you really intend to undo the previous patch?
Cheers,
Peter
LEGAL_NEW_RESOURCE(stuff-barrier, client);
err = dixLookupWindow(pWin, stuff-window, client, DixReadAccess);
@@ -1304,9 +1310,9 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
if (barrier_is_horizontal(b) barrier_is_vertical(b))
return BadValue;
-if (!(barrier = CreatePointerBarrierClient(pWin-drawable.pScreen,
- client, stuff)))
-return BadAlloc;
+if ((err = CreatePointerBarrierClient(pWin-drawable.pScreen,
+ client, stuff, barrier)))
+return err;
if (!AddResource(stuff-barrier, PointerBarrierType, barrier-barrier))
return BadAlloc;
@@ -1318,13 +1324,9 @@ int
SProcXFixesCreatePointerBarrier(ClientPtr client)
{
REQUEST(xXFixesCreatePointerBarrierReq);
-int i;
-CARD16 *in_devices = (CARD16 *) stuff[1];
swaps(stuff-length);
-swaps(stuff-num_devices);
-REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq,
pad_to_int32(stuff-num_devices));
-
+REQUEST_SIZE_MATCH(xXFixesCreatePointerBarrierReq);
swapl(stuff-barrier);
swapl(stuff-window);
swaps(stuff-x1);
@@ -1332,10 +1334,6 @@ SProcXFixesCreatePointerBarrier(ClientPtr client)
swaps(stuff-x2);
swaps(stuff-y2);
swapl(stuff-directions);
-for (i = 0; i stuff-num_devices; i++) {
-swapl(in_devices + i);
-}
-
return ProcXFixesVector[stuff-xfixesReqType] (client);
}
--
1.7.12.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/5] cursor: Clean up pointer barrier creation code a tiny bit
From: Jasper St. Pierre jstpie...@mecheye.net
This will make it much simpler when we add more error paths to the code
that constructs pointer barrier clients.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
xfixes/cursor.c | 54 ++
1 file changed, 26 insertions(+), 28 deletions(-)
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 9d7c0f0..a34f65c 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -1245,28 +1245,34 @@ CursorConstrainCursorHarder(DeviceIntPtr dev, ScreenPtr
screen, int mode,
}
}
-static struct PointerBarrierClient *
+static int
CreatePointerBarrierClient(ScreenPtr screen, ClientPtr client,
- xXFixesCreatePointerBarrierReq * stuff)
+ xXFixesCreatePointerBarrierReq * stuff,
+ PointerBarrierClientPtr *client_out)
{
CursorScreenPtr cs = GetCursorScreen(screen);
struct PointerBarrierClient *ret = malloc(sizeof(*ret));
-if (ret) {
-ret-screen = screen;
-ret-barrier.x1 = min(stuff-x1, stuff-x2);
-ret-barrier.x2 = max(stuff-x1, stuff-x2);
-ret-barrier.y1 = min(stuff-y1, stuff-y2);
-ret-barrier.y2 = max(stuff-y1, stuff-y2);
-ret-barrier.directions = stuff-directions 0x0f;
-if (barrier_is_horizontal(ret-barrier))
-ret-barrier.directions = ~(BarrierPositiveX | BarrierNegativeX);
-if (barrier_is_vertical(ret-barrier))
-ret-barrier.directions = ~(BarrierPositiveY | BarrierNegativeY);
-xorg_list_add(ret-entry, cs-barriers);
+*client_out = NULL;
+
+if (!ret) {
+return BadAlloc;
}
-return ret;
+ret-screen = screen;
+ret-barrier.x1 = min(stuff-x1, stuff-x2);
+ret-barrier.x2 = max(stuff-x1, stuff-x2);
+ret-barrier.y1 = min(stuff-y1, stuff-y2);
+ret-barrier.y2 = max(stuff-y1, stuff-y2);
+ret-barrier.directions = stuff-directions 0x0f;
+if (barrier_is_horizontal(ret-barrier))
+ret-barrier.directions = ~(BarrierPositiveX | BarrierNegativeX);
+if (barrier_is_vertical(ret-barrier))
+ret-barrier.directions = ~(BarrierPositiveY | BarrierNegativeY);
+xorg_list_add(ret-entry, cs-barriers);
+
+*client_out = ret;
+return Success;
}
int
@@ -1279,7 +1285,7 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
REQUEST(xXFixesCreatePointerBarrierReq);
-REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq,
pad_to_int32(stuff-num_devices));
+REQUEST_SIZE_MATCH(xXFixesCreatePointerBarrierReq);
LEGAL_NEW_RESOURCE(stuff-barrier, client);
err = dixLookupWindow(pWin, stuff-window, client, DixReadAccess);
@@ -1304,9 +1310,9 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
if (barrier_is_horizontal(b) barrier_is_vertical(b))
return BadValue;
-if (!(barrier = CreatePointerBarrierClient(pWin-drawable.pScreen,
- client, stuff)))
-return BadAlloc;
+if ((err = CreatePointerBarrierClient(pWin-drawable.pScreen,
+ client, stuff, barrier)))
+return err;
if (!AddResource(stuff-barrier, PointerBarrierType, barrier-barrier))
return BadAlloc;
@@ -1318,13 +1324,9 @@ int
SProcXFixesCreatePointerBarrier(ClientPtr client)
{
REQUEST(xXFixesCreatePointerBarrierReq);
-int i;
-CARD16 *in_devices = (CARD16 *) stuff[1];
swaps(stuff-length);
-swaps(stuff-num_devices);
-REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq,
pad_to_int32(stuff-num_devices));
-
+REQUEST_SIZE_MATCH(xXFixesCreatePointerBarrierReq);
swapl(stuff-barrier);
swapl(stuff-window);
swaps(stuff-x1);
@@ -1332,10 +1334,6 @@ SProcXFixesCreatePointerBarrier(ClientPtr client)
swaps(stuff-x2);
swaps(stuff-y2);
swapl(stuff-directions);
-for (i = 0; i stuff-num_devices; i++) {
-swapl(in_devices + i);
-}
-
return ProcXFixesVector[stuff-xfixesReqType] (client);
}
--
1.7.12.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/5] cursor: Clean up pointer barrier creation code a tiny bit
From: Jasper St. Pierre jstpie...@mecheye.net
This will make it much simpler when we add more error paths to the code
that constructs pointer barrier clients.
Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net
---
xfixes/cursor.c | 42 --
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/xfixes/cursor.c b/xfixes/cursor.c
index 75b0374..f66bd68 100644
--- a/xfixes/cursor.c
+++ b/xfixes/cursor.c
@@ -1245,28 +1245,34 @@ CursorConstrainCursorHarder(DeviceIntPtr dev, ScreenPtr
screen, int mode,
}
}
-static struct PointerBarrierClient *
+static int
CreatePointerBarrierClient(ScreenPtr screen, ClientPtr client,
- xXFixesCreatePointerBarrierReq * stuff)
+ xXFixesCreatePointerBarrierReq * stuff,
+ PointerBarrierClientPtr *client_out)
{
CursorScreenPtr cs = GetCursorScreen(screen);
struct PointerBarrierClient *ret = malloc(sizeof(*ret));
-if (ret) {
-ret-screen = screen;
-ret-barrier.x1 = min(stuff-x1, stuff-x2);
-ret-barrier.x2 = max(stuff-x1, stuff-x2);
-ret-barrier.y1 = min(stuff-y1, stuff-y2);
-ret-barrier.y2 = max(stuff-y1, stuff-y2);
-ret-barrier.directions = stuff-directions 0x0f;
-if (barrier_is_horizontal(ret-barrier))
-ret-barrier.directions = ~(BarrierPositiveX | BarrierNegativeX);
-if (barrier_is_vertical(ret-barrier))
-ret-barrier.directions = ~(BarrierPositiveY | BarrierNegativeY);
-xorg_list_add(ret-entry, cs-barriers);
+*client_out = NULL;
+
+if (!ret) {
+return BadAlloc;
}
-return ret;
+ret-screen = screen;
+ret-barrier.x1 = min(stuff-x1, stuff-x2);
+ret-barrier.x2 = max(stuff-x1, stuff-x2);
+ret-barrier.y1 = min(stuff-y1, stuff-y2);
+ret-barrier.y2 = max(stuff-y1, stuff-y2);
+ret-barrier.directions = stuff-directions 0x0f;
+if (barrier_is_horizontal(ret-barrier))
+ret-barrier.directions = ~(BarrierPositiveX | BarrierNegativeX);
+if (barrier_is_vertical(ret-barrier))
+ret-barrier.directions = ~(BarrierPositiveY | BarrierNegativeY);
+xorg_list_add(ret-entry, cs-barriers);
+
+*client_out = ret;
+return Success;
}
int
@@ -1304,9 +1310,9 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
if (barrier_is_horizontal(b) barrier_is_vertical(b))
return BadValue;
-if (!(barrier = CreatePointerBarrierClient(pWin-drawable.pScreen,
- client, stuff)))
-return BadAlloc;
+if ((err = CreatePointerBarrierClient(pWin-drawable.pScreen,
+ client, stuff, barrier)))
+return err;
if (!AddResource(stuff-barrier, PointerBarrierType, barrier-barrier))
return BadAlloc;
--
1.7.12.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH fixesproto] fixesproto v6: Pointer barrier thresholds
one will be represented in
+ this list.
+
+ barrier is the ID of the barrier hit.
+
+ Type indicates the trigger of the event:
+Hit when the barrier has prevented pointer movement.
+ThresholdExceeded when the barrier has been hit but has not
+ prevented pointer movement due to the threshold being exceeded.
+PointerReleased when the barrier would have blocked motion but
+ has been rendered permeable by a BarrierReleasePointer request.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier and remains
+ valid until the first input event from deviceid which is not
+ restricted by the barrier. The event-id is unique per-barrier.
+
+ Since a barrier event is associated with a deviceid there can be more
+ than one event active for a given barrier simultaneously.
+
+
+13.3 Requests
+
+SelectBarrierInput
+
+ event-mask: SETofBarrierEvent
+
+ This request directs barrier events to the client which issued the
+ request.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not initially block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ A pointer hitting the barrier results in a BarrierNotify event in the
+ same way as a regular PointerBarrier. This event is sent whether or not
+ the threshold velocity was exceeded.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event unless released by a
+ BarrierReleasePointer request.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barriers: LISTof{ BARRIER,
+ BarrierEventID}
+
+ Temporarily allow the pointer to pass through a set of pointer
+ barriers. For each barrier in barriers this allows the pointer to pass
+ through for as long as the corresponding event-id is valid.
+
+ A single barrier may appear in barriers more than once with a
+ different associated event-id each time. In this way a client can
+ release a barrier for multiple input devices in one request.
+
+ If a requested event-id is not current for its associated barrier
+ then that, and only that, part of the request is silently ignored.
+
+ If the same (barrier, event-id) pair appears more than once in
+ barriers then the request behaves as if that pair appeared exactly
+ once.
+
+ Errors: Barrier
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..2df8211 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,82 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct
+{
+Barrierbarrier B32;
+CARD32 type B32;
+BarrierEventID event_id B32;
+} xXFixesBarrierEventDetails;
+
+typedef struct
+{
+CARD8 type; /* Always GenericEvent */
+CARD8 extension; /* XFIXES extension offset */
+CARD16sequenceNumber B16;
+CARD32length B32; /* Length in 4 byte units */
+CARD16evtype B16; /* Always BarrierNotify */
+INT16 deviceid B16;
+WINDOWwindow B32;
+INT16 x B16;
+INT16 y B16;
+FP3232dx;
+FP3232dy;
+FP3232raw-dx;
+FP3232raw-dy;
+INT16 dt B16;
+INT16 num_eventdetails B16;
+/* Array of BarrierEventDetails */
+} xXFixesBarrierNotifyEvent;
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Barrier barrier B32;
+Window window B32;
+INT16 x1 B16;
+INT16 y1 B16;
+INT16 x2 B16;
+INT16 y2 B16;
+CARD32 directions;
+CARD32 velocity;
+CARD16 pad B16;
+CARD16 num_devices B16;
+/* array of CARD16 devices */
+} xXFixesCreatePointerBarrierVelocityReq;
+
+#define sz_xXFixesCreatePointerBarrierVelocityReq 32
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+CARD32 eventMask
Re: [PATCH x11proto-fixes (v2)] fixesproto v6: Pointer barrier thresholds
restricted by the barrier and remains
+ valid until the first input event from deviceid which is not
+ restricted by the barrier. The event-id is unique per-barrier.
+
+ Since a barrier event is associated with a deviceid there can be more
+ than one event active for a given barrier simultaneously.
+
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+ This request directs barrier events to the named window.
that is weird. why not send the events to the client that issued the
request? what happens when the window becomes unviewable and how is this
window related to the drawable in the CreatePointerBarrier request?
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not initially block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event unless released by a
+ BarrierReleasePointer request.
missing:
A pointer hitting the barrier results in a BarrierNotify event.
(should be added to the CreatePointerBarrier blurb too)
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barriers: LISTof{ BARRIER,
+ BarrierEventID}
+
+ Temporarily allow the pointer to pass through a set of pointer
+ barriers. For each barrier in barriers this allows the pointer to pass
+ through for as long as the corresponding event-id is valid.
+
+ A single barrier may appear in barriers more than once with a
+ different associated event-id each time. In this way a client can
+ release a barrier for multiple input devices in one request.
+
+ If a requested event-id is not current for its associated barrier
+ then that, and only that, part of the request is silently ignored.
+
+ If the same (barrier, event-id) pair appears more than once in
+ barriers then the request behaves as if that pair appeared exactly
+ once.
+
+ Errors: Barrier
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..bb1949b 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,70 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct
+{
+CARD8 type; /* Always GenericEvent */
+CARD8 extension; /* XFIXES extension offset */
+CARD16sequenceNumber;
+CARD32length; /* Length in 4 byte units */
+CARD16evtype; /* Always BarrierNotify */
+WINDOWwindow;
+INT16 x;
+INT16 y;
+FP3232dx;
+FP3232dy;
+FP3232raw-dx;
+FP3232raw-dy;
+INT16 dt;
+INT16 deviceid;
+INT16 num_eventdetails;
+/* Array of BarrierEventDetails */
+} xXFixesBarrierNotifyEvent;
you need to shuffle this around so everything is 4-byte aligned. moving
deviceid after evtype would do the job here. Don't forget the B32, B16 stuff
here too.
BarrierEventDetails should have a struct too.
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Barrier barrier B32;
+Window window B32;
+INT16 x1 B16;
+INT16 y1 B16;
+INT16 x2 B16;
+INT16 y2 B16;
+CARD32 directions;
+CARD32 velocity;
+CARD16 pad B16;
+CARD16 num_devices B16;
+/* array of CARD16 devices */
+} xXFixesCreatePointerBarrierVelocityReq;
+
+#define sz_xXFixesCreatePointerBarrierVelocityReq 32
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Window window B32;
+CARD32 eventMask B32;
+} xXFixesSelectBarrierInputReq;
+
+#define sz_xXFixesSelectBarrierInputReq 12
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+CARD16 num_barriers;
+/* array of BARRIER, BarrierEventID */
+} xXFixesBarrierReleasePointerReq;
I'd prefer some struct here again.
rest
[PATCH x11proto-fixes (v2)] fixesproto v6: Pointer barrier thresholds
+
+ This request directs barrier events to the named window.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not initially block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event unless released by a
+ BarrierReleasePointer request.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barriers: LISTof{ BARRIER,
+ BarrierEventID}
+
+ Temporarily allow the pointer to pass through a set of pointer
+ barriers. For each barrier in barriers this allows the pointer to pass
+ through for as long as the corresponding event-id is valid.
+
+ A single barrier may appear in barriers more than once with a
+ different associated event-id each time. In this way a client can
+ release a barrier for multiple input devices in one request.
+
+ If a requested event-id is not current for its associated barrier
+ then that, and only that, part of the request is silently ignored.
+
+ If the same (barrier, event-id) pair appears more than once in
+ barriers then the request behaves as if that pair appeared exactly
+ once.
+
+ Errors: Barrier
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..bb1949b 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,70 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct
+{
+CARD8 type; /* Always GenericEvent */
+CARD8 extension; /* XFIXES extension offset */
+CARD16sequenceNumber;
+CARD32length; /* Length in 4 byte units */
+CARD16evtype; /* Always BarrierNotify */
+WINDOWwindow;
+INT16 x;
+INT16 y;
+FP3232dx;
+FP3232dy;
+FP3232raw-dx;
+FP3232raw-dy;
+INT16 dt;
+INT16 deviceid;
+INT16 num_eventdetails;
+/* Array of BarrierEventDetails */
+} xXFixesBarrierNotifyEvent;
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Barrier barrier B32;
+Window window B32;
+INT16 x1 B16;
+INT16 y1 B16;
+INT16 x2 B16;
+INT16 y2 B16;
+CARD32 directions;
+CARD32 velocity;
+CARD16 pad B16;
+CARD16 num_devices B16;
+/* array of CARD16 devices */
+} xXFixesCreatePointerBarrierVelocityReq;
+
+#define sz_xXFixesCreatePointerBarrierVelocityReq 32
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Window window B32;
+CARD32 eventMask B32;
+} xXFixesSelectBarrierInputReq;
+
+#define sz_xXFixesSelectBarrierInputReq12
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+CARD16 num_barriers;
+/* array of BARRIER, BarrierEventID */
+} xXFixesBarrierReleasePointerReq;
+
+#define sz_xXFixesBarrierReleasePointerReq 6
+
+#undef BarrierEventID
#undef Barrier
#undef Region
#undef Picture
diff --git a/xfixeswire.h b/xfixeswire.h
index 432349a..e3a23c7 100644
--- a/xfixeswire.h
+++ b/xfixeswire.h
@@ -48,7 +48,7 @@
#define _XFIXESWIRE_H_
#define XFIXES_NAMEXFIXES
-#define XFIXES_MAJOR 5
+#define XFIXES_MAJOR 6
#define XFIXES_MINOR 0
/*** Version 1 **/
@@ -89,8 +89,12 @@
/*** Version 5 **/
#define X_XFixesCreatePointerBarrier 31
#define X_XFixesDestroyPointerBarrier 32
+/*** Version 6 **/
+#define X_XFixesCreatePointerBarrierVelocity 33
+#define X_XFixesSelectBarrierInput 34
+#define X_XFixesBarrierReleasePointer 35
-#define XFixesNumberRequests (X_XFixesDestroyPointerBarrier+1)
+#define XFixesNumberRequests (X_XFixesBarrierReleasePointer+1)
/* Selection events share one event number */
#define XFixesSelectionNotify 0
@@ -136,4 +140,16 @@
#define BarrierNegativeX (1L 2
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
enough? isn't the accelerated data of more
interest since it maps much more against what the user is trying to do?
I have no clue what data the driver submits, but I have a rough feeling of
how much the mouse will move when I do.
s/valuator/valuators
typo: purpendicular
And I thought I'd spell-checked it. Oops :).
+ to the barrier) and time-since-last-input-event for deviceid
+ respectively.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
event-id is unique per-device? per-server? per-something?
I assume the second, given that device id isn't required to release the
pointer, might be worth pointing out.
Unique per-barrier per-server, modulo wrap around. I'll make this
clearer.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
should state that px/sec is after acceleration is applied (i suspect that's
the case) just to make sure that's clear
Yup.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
+ event-id: BarrierEventID
+
+ Temporarily allow the pointer to pass through a pointer barrier.
+ This disables the barrier for as long as event-id is valid - that is,
+ as long as the pointer remains in contact with the barrier.
+
+ Requests to release the pointer for an event-id which is not current
+ are silently ignored.
+
+ Errors: Barrier
+
+
is there a need for this to take a number of event-ids?
corner-case, certainly, I admit.
Hm. Given that I've earlier said that in the case of multiple
overlapping barriers an event is sent for each, this might indeed be
necessary.
To properly support multiple overlapping barriers I think there'd need
to be changes elsewhere. Specifically, if a single pointer event is
blocked by multiple barriers the server sends out an event for each
barrier, but the client has no way of knowing whether that's a response
to a single pointer movement or not.
This could easily be supported by adding an extra field to the
BarrierEvent for the number of subsequent events triggered by the same
pointer event.
I'm not sure if this is worth doing.
if you use GenericEvents you have space and you can pack all Barriers hit by
a single pointer movement into the same event.
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..4e2d3d6 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,65 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct {
+ CARD8 type;
+ CARD8 subtype;
+ CARD16 sequenceNumber B16;
+ Window window; B32;
+ BarrierEventID event_id B32;
+ Barrier barrier;
+ CARD32 velocity B32;
+ INT16 x B16;
+ INT16 y B16;
+ CARD32 raw_displacement B32;
+ CARD16 delta_t B16;
+ CARD16 deviceid B16;
+} xXFixesBarrierNotifyEvent;
see generic event comment
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Barrier barrier B32;
+Window window B32;
+INT16 x1 B16;
+INT16 y1 B16;
+INT16 x2 B16;
+INT16 y2 B16;
+CARD32 directions;
+CARD32 velocity;
+CARD16 pad B16;
+CARD16 num_devices B16;
+/* array of CARD16 devices */
+} xXFixesCreatePointerBarrierVelocityReq;
+
+#define sz_xXFixesCreatePointerBarrierVelocityReq 32
it'd be great to shoehorn this into the existing request but I suspect that
has a potential to break things. so reluctantly ack
It'd be a SMOP to have the server/libxfixes use a different request
based on whether or not both sides support
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Thu, 2012-05-03 at 16:35 +1000, Peter Hutterer wrote:
On Thu, May 03, 2012 at 12:40:58PM +1000, Christopher James Halse Rogers
wrote:
On Thu, 2012-05-03 at 11:05 +1000, Peter Hutterer wrote:
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers
wrote:
---
I've got a corresponding xserver patch, but it needs updating for the
Great Reindent of '12. Might as well get support for the protocol
additions
before fixing it up.
A slightly different variant of this (it's gone through a number of
iterations
in conjunction with the Unity team) is used by the Unity shell as
infrastructure
for the one-launcher-per-display support, so there's evidence that it's
a usable
protocol.
looks good, a few minor clarifications are needed below. The main change
I'd
like to see is a change to use generic events instead of a standard
event..
I'll finish reading up on how to make that happen, then :)
we've hit the maximum event number in the past, adding another non-generic
event can cause us to stretch over the limit.
http://lists.x.org/archives/xorg-devel/2010-March/006716.html
configure.ac |2 +-
fixesproto.txt | 94
xfixesproto.h | 59 +++
xfixeswire.h | 23 +++--
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6f8c705 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,100 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer
through
+when a threshold is reached. This can be useful for desktop
environments that
+wish to use a large region of the screen, such as an entire edge, to
provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ velocity: CARD32
+ x, y: INT16
+ raw-displacement: FP1616
+ delta-t:INT16
+ deviceid: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window.
Subtype
+ indicates the trigger of the event, which is Hit when the
barrier has
+ prevented pointer movement and ThresholdExceeded when the
barrier has
+ been hit but has not prevented pointer movement due to the
threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y)
contain
+ the coordinates of the pointer after restriction by any
applicable
+ barriers, and velocity is the unrestricted instantaneous
velocity
+ of the pointer, perpendicular to the barrier.
how is velocity defined?
(edit: found it below, this should be either in some common section or
everywhere. You could just define a VELOCITY type and explain it there)
That makes sense, I'll do so.
+
+ deviceid is the identifier of the device which caused the
barrier
+ event, raw-displacement and delta-t are the raw valuator
(purpendicular
I'm not sure what you raw-displacement here is, can you clarify?
Raw-displacement is exactly the value you'd get if you were subscribed
to XI 2 raw events and selected the valuator perpendicular to the
barrier.
It (and delta-t) are here so that a client can get a pre-acceleration
idea of the velocity and user behaviour if the client desires. This is
useful for clients to determine when they want to
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Fri, May 04, 2012 at 09:46:47AM +1000, Christopher James Halse Rogers wrote:
On Thu, 2012-05-03 at 16:35 +1000, Peter Hutterer wrote:
On Thu, May 03, 2012 at 12:40:58PM +1000, Christopher James Halse Rogers
wrote:
On Thu, 2012-05-03 at 11:05 +1000, Peter Hutterer wrote:
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse
Rogers wrote:
---
I've got a corresponding xserver patch, but it needs updating for the
Great Reindent of '12. Might as well get support for the protocol
additions
before fixing it up.
A slightly different variant of this (it's gone through a number of
iterations
in conjunction with the Unity team) is used by the Unity shell as
infrastructure
for the one-launcher-per-display support, so there's evidence that
it's a usable
protocol.
looks good, a few minor clarifications are needed below. The main
change I'd
like to see is a change to use generic events instead of a standard
event..
I'll finish reading up on how to make that happen, then :)
we've hit the maximum event number in the past, adding another
non-generic
event can cause us to stretch over the limit.
http://lists.x.org/archives/xorg-devel/2010-March/006716.html
configure.ac |2 +-
fixesproto.txt | 94
xfixesproto.h | 59 +++
xfixeswire.h | 23 +++--
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6f8c705 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,100 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer
through
+when a threshold is reached. This can be useful for desktop
environments that
+wish to use a large region of the screen, such as an entire edge, to
provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ velocity: CARD32
+ x, y: INT16
+ raw-displacement: FP1616
+ delta-t:INT16
+ deviceid: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window.
Subtype
+ indicates the trigger of the event, which is Hit when the
barrier has
+ prevented pointer movement and ThresholdExceeded when the
barrier has
+ been hit but has not prevented pointer movement due to the
threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y)
contain
+ the coordinates of the pointer after restriction by any
applicable
+ barriers, and velocity is the unrestricted instantaneous
velocity
+ of the pointer, perpendicular to the barrier.
how is velocity defined?
(edit: found it below, this should be either in some common section or
everywhere. You could just define a VELOCITY type and explain it there)
That makes sense, I'll do so.
+
+ deviceid is the identifier of the device which caused the
barrier
+ event, raw-displacement and delta-t are the raw valuator
(purpendicular
I'm not sure what you raw-displacement here is, can you clarify?
Raw-displacement is exactly the value you'd get if you were subscribed
to XI 2 raw events and selected the valuator perpendicular to the
barrier.
It (and delta-t) are
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers wrote:
---
I've got a corresponding xserver patch, but it needs updating for the
Great Reindent of '12. Might as well get support for the protocol additions
before fixing it up.
A slightly different variant of this (it's gone through a number of iterations
in conjunction with the Unity team) is used by the Unity shell as
infrastructure
for the one-launcher-per-display support, so there's evidence that it's a
usable
protocol.
looks good, a few minor clarifications are needed below. The main change I'd
like to see is a change to use generic events instead of a standard event.
we've hit the maximum event number in the past, adding another non-generic
event can cause us to stretch over the limit.
http://lists.x.org/archives/xorg-devel/2010-March/006716.html
configure.ac |2 +-
fixesproto.txt | 94
xfixesproto.h | 59 +++
xfixeswire.h | 23 +++--
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6f8c705 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,100 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments
that
+wish to use a large region of the screen, such as an entire edge, to provide
a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ velocity: CARD32
+ x, y: INT16
+ raw-displacement: FP1616
+ delta-t:INT16
+ deviceid: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y) contain
+ the coordinates of the pointer after restriction by any applicable
+ barriers, and velocity is the unrestricted instantaneous velocity
+ of the pointer, perpendicular to the barrier.
how is velocity defined?
(edit: found it below, this should be either in some common section or
everywhere. You could just define a VELOCITY type and explain it there)
+
+ deviceid is the identifier of the device which caused the barrier
+ event, raw-displacement and delta-t are the raw valuator (purpendicular
I'm not sure what you raw-displacement here is, can you clarify?
s/valuator/valuators
typo: purpendicular
+ to the barrier) and time-since-last-input-event for deviceid
+ respectively.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
event-id is unique per-device? per-server? per-something?
I assume the second, given that device id isn't required to release the
pointer, might be worth pointing out.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers wrote:
---
I've got a corresponding xserver patch, but it needs updating for the
Great Reindent of '12. Might as well get support for the protocol additions
before fixing it up.
A slightly different variant of this (it's gone through a number of iterations
in conjunction with the Unity team) is used by the Unity shell as
infrastructure
for the one-launcher-per-display support, so there's evidence that it's a
usable
protocol.
configure.ac |2 +-
fixesproto.txt | 94
xfixesproto.h | 59 +++
xfixeswire.h | 23 +++--
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6f8c705 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,100 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments
that
+wish to use a large region of the screen, such as an entire edge, to provide
a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ velocity: CARD32
+ x, y: INT16
+ raw-displacement: FP1616
+ delta-t:INT16
+ deviceid: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y) contain
+ the coordinates of the pointer after restriction by any applicable
+ barriers, and velocity is the unrestricted instantaneous velocity
+ of the pointer, perpendicular to the barrier.
+
+ deviceid is the identifier of the device which caused the barrier
+ event, raw-displacement and delta-t are the raw valuator (purpendicular
+ to the barrier) and time-since-last-input-event for deviceid
+ respectively.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
+
+ In the case of multiple overlapping barriers an event is sent for each.
are events triggered on barriers without velocity?
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
+ event-id: BarrierEventID
+
+ Temporarily allow the pointer to pass through a pointer barrier.
+ This disables the barrier for as long as event-id is valid - that is,
+ as long as the pointer
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
to release the
pointer, might be worth pointing out.
Unique per-barrier per-server, modulo wrap around. I'll make this
clearer.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
should state that px/sec is after acceleration is applied (i suspect that's
the case) just to make sure that's clear
Yup.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
+ event-id: BarrierEventID
+
+ Temporarily allow the pointer to pass through a pointer barrier.
+ This disables the barrier for as long as event-id is valid - that is,
+ as long as the pointer remains in contact with the barrier.
+
+ Requests to release the pointer for an event-id which is not current
+ are silently ignored.
+
+ Errors: Barrier
+
+
is there a need for this to take a number of event-ids?
corner-case, certainly, I admit.
Hm. Given that I've earlier said that in the case of multiple
overlapping barriers an event is sent for each, this might indeed be
necessary.
To properly support multiple overlapping barriers I think there'd need
to be changes elsewhere. Specifically, if a single pointer event is
blocked by multiple barriers the server sends out an event for each
barrier, but the client has no way of knowing whether that's a response
to a single pointer movement or not.
This could easily be supported by adding an extra field to the
BarrierEvent for the number of subsequent events triggered by the same
pointer event.
I'm not sure if this is worth doing.
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..4e2d3d6 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,65 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct {
+ CARD8 type;
+ CARD8 subtype;
+ CARD16 sequenceNumber B16;
+ Window window; B32;
+ BarrierEventID event_id B32;
+ Barrier barrier;
+ CARD32 velocity B32;
+ INT16 x B16;
+ INT16 y B16;
+ CARD32 raw_displacement B32;
+ CARD16 delta_t B16;
+ CARD16 deviceid B16;
+} xXFixesBarrierNotifyEvent;
see generic event comment
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Barrier barrier B32;
+Window window B32;
+INT16 x1 B16;
+INT16 y1 B16;
+INT16 x2 B16;
+INT16 y2 B16;
+CARD32 directions;
+CARD32 velocity;
+CARD16 pad B16;
+CARD16 num_devices B16;
+/* array of CARD16 devices */
+} xXFixesCreatePointerBarrierVelocityReq;
+
+#define sz_xXFixesCreatePointerBarrierVelocityReq 32
it'd be great to shoehorn this into the existing request but I suspect that
has a potential to break things. so reluctantly ack
It'd be a SMOP to have the server/libxfixes use a different request
based on whether or not both sides support fixes v6, but that would be
an extra piece to get wrong.
Cheers,
Peter
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Window window B32;
+CARD32 eventMask B32;
+} xXFixesSelectBarrierInputReq;
+
+#define sz_xXFixesSelectBarrierInputReq12
+
+typedef struct {
+CARD8 reqType;
+CARD8 xfixesReqType;
+CARD16 length B16;
+Barrier barrier B32;
+BarrierEventID event_id B32;
+} xXFixesBarrierReleasePointerReq;
+
+#define sz_xXFixesBarrierReleasePointerReq 12
+
+#undef BarrierEventID
#undef Barrier
#undef Region
#undef Picture
diff --git a/xfixeswire.h b/xfixeswire.h
index 432349a..0230595 100644
--- a/xfixeswire.h
+++ b/xfixeswire.h
@@ -48,7 +48,7 @@
#define _XFIXESWIRE_H_
#define XFIXES_NAMEXFIXES
-#define XFIXES_MAJOR 5
+#define XFIXES_MAJOR 6
#define XFIXES_MINOR
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Thu, 2012-05-03 at 11:12 +1000, Peter Hutterer wrote:
On Tue, Apr 03, 2012 at 01:42:38PM +1000, Christopher James Halse Rogers
wrote:
---
I've got a corresponding xserver patch, but it needs updating for the
Great Reindent of '12. Might as well get support for the protocol
additions
before fixing it up.
A slightly different variant of this (it's gone through a number of
iterations
in conjunction with the Unity team) is used by the Unity shell as
infrastructure
for the one-launcher-per-display support, so there's evidence that it's a
usable
protocol.
configure.ac |2 +-
fixesproto.txt | 94
xfixesproto.h | 59 +++
xfixeswire.h | 23 +++--
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6f8c705 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,100 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer
through
+when a threshold is reached. This can be useful for desktop environments
that
+wish to use a large region of the screen, such as an entire edge, to
provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ velocity: CARD32
+ x, y: INT16
+ raw-displacement: FP1616
+ delta-t:INT16
+ deviceid: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y) contain
+ the coordinates of the pointer after restriction by any applicable
+ barriers, and velocity is the unrestricted instantaneous velocity
+ of the pointer, perpendicular to the barrier.
+
+ deviceid is the identifier of the device which caused the barrier
+ event, raw-displacement and delta-t are the raw valuator (purpendicular
+ to the barrier) and time-since-last-input-event for deviceid
+ respectively.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
+
+ In the case of multiple overlapping barriers an event is sent for each.
are events triggered on barriers without velocity?
Yes. I could make this more obvious by explicitly stating that barriers
without velocity will never send ThresholdExceeded.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Tue, 2012-04-03 at 13:42 +1000, Christopher James Halse Rogers wrote: --- I've got a corresponding xserver patch, but it needs updating for the Great Reindent of '12. Might as well get support for the protocol additions before fixing it up. A slightly different variant of this (it's gone through a number of iterations in conjunction with the Unity team) is used by the Unity shell as infrastructure for the one-launcher-per-display support, so there's evidence that it's a usable protocol. configure.ac |2 +- fixesproto.txt | 94 xfixesproto.h | 59 +++ xfixeswire.h | 23 +++-- 4 files changed, 173 insertions(+), 5 deletions(-) Ping? Anything I can do to help make this more attractive to review? Send the server and libxfixes implementation patch, work out why xcb doesn't like fixes v5, promise beer, etc? signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] fixesproto v6: Pointer barrier thresholds
On Tue, 2012-04-03 at 13:42 +1000, Christopher James Halse Rogers wrote: --- I've got a corresponding xserver patch, but it needs updating for the Great Reindent of '12. Might as well get support for the protocol additions before fixing it up. A slightly different variant of this (it's gone through a number of iterations in conjunction with the Unity team) is used by the Unity shell as infrastructure for the one-launcher-per-display support, so there's evidence that it's a usable protocol. configure.ac |2 +- fixesproto.txt | 94 xfixesproto.h | 59 +++ xfixeswire.h | 23 +++-- 4 files changed, 173 insertions(+), 5 deletions(-) Ping? Anything I can do to help make this more attractive to review? Send the server and libxfixes implementation patch, work out why xcb doesn't like fixes v5, promise beer, etc? signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] fixesproto v6: Pointer barrier thresholds
---
I've got a corresponding xserver patch, but it needs updating for the
Great Reindent of '12. Might as well get support for the protocol additions
before fixing it up.
A slightly different variant of this (it's gone through a number of iterations
in conjunction with the Unity team) is used by the Unity shell as infrastructure
for the one-launcher-per-display support, so there's evidence that it's a usable
protocol.
configure.ac |2 +-
fixesproto.txt | 94
xfixesproto.h | 59 +++
xfixeswire.h | 23 +++--
4 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index f85b802..07dd29a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([FixesProto], [5.0],
+AC_INIT([FixesProto], [6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..6f8c705 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,100 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ velocity: CARD32
+ x, y: INT16
+ raw-displacement: FP1616
+ delta-t:INT16
+ deviceid: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y) contain
+ the coordinates of the pointer after restriction by any applicable
+ barriers, and velocity is the unrestricted instantaneous velocity
+ of the pointer, perpendicular to the barrier.
+
+ deviceid is the identifier of the device which caused the barrier
+ event, raw-displacement and delta-t are the raw valuator (purpendicular
+ to the barrier) and time-since-last-input-event for deviceid
+ respectively.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ velocity: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
+ event-id: BarrierEventID
+
+ Temporarily allow the pointer to pass through a pointer barrier.
+ This disables the barrier for as long as event-id is valid - that is,
+ as long as the pointer remains in contact with the barrier.
+
+ Requests to release the pointer for an event-id which is not current
+ are silently ignored.
+
+ Errors
[RFC PATCH v2] fixesproto v6: Pointer barrier improvements.
From: Christopher James Halse Rogers r...@ubuntu.com
Adds a velocity-gated pointer barrier, events to notify a client when barriers
are hit, and a mechanism for clients to temporarily allow movement through
a barrier.
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
After further prototyping with DX it became clear that, apart from the
initial block, the logic really needed to be client-side. Which, fortunately,
makes for a nicer protocol. Yay!
fixesproto.txt | 86
xfixesproto.h | 44
xfixeswire.h | 24 +--
3 files changed, 150 insertions(+), 4 deletions(-)
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..5e680f0 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,92 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierThresholdKind: {None, Velocity, HitCount}
+ BarrierEvent: {Hit, ThresholdExceeded}
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ barrier:BARRIER
+ kind: BarrierThresholdKind
+ threshold: CARD32
+ timestamp: Timestamp
+ value: CARD32
+ x, y: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered, which has a
+ threshold type of kind and threshold value threshold. The value of
+ the property which is compared against the threshold was value.
+
+ (x,y) contain the coordinates of the pointer after restriction by any
+ applicable barriers.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierThreshold
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ type: BarrierThresholdKind
+ threshold: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold is
+ exceeded.
+
+ Type can be None, in which case behaviour is identical to
+ CreatePointerBarrier and threshold is ignored.
+
+ Type can be Velocity, in which case the pointer will pass through the
+ barrier if the instantaneous velocity perpendicular to the barrier
+ in px/sec is greater than threshold.
+
+ Type can be HitCount, in which case the pointer will pass through the
+ barrier once the barrier has been hit threshold times. The count is
+ not automatically reset, so once the threshold has been reached the
+ barrier will not block any further pointer movement.
+
+ If type is not one of these values, BadValue is generated.
+
+ In the case of overlapping barriers each one is tested against, even
+ after the first one blocks the pointer.
+
+ Errors: IDChoice, Window, Value, Device
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..d4d657c 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,50 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+typedef struct {
+ CARD8 type;
+ CARD8 subtype;
+ CARD16 sequenceNumber B16;
+ Window window; B32;
+ CARD32 directions;
+ Barrier barrier;
+ INT16 x B16;
+ INT16 y B16;
+ CARD32 velocity B32;
+ Time timestamp B32
Re: [RFC PATCH v2] fixesproto v6: Pointer barrier improvements.
_X_EXPORT RESTYPE PointerBarrierType;
@@ -52,9 +53,27 @@ extern _X_EXPORT int XFixesErrorBase;
extern _X_EXPORT RegionPtr
XFixesRegionCopy (RegionPtr pRegion);
+typedef struct PointerBarrierEventClient *PointerBarrierEventClientPtr;
+
+struct PointerBarrierEventClient {
+ScreenPtr screen;
+ClientPtr client;
+CARD32eventMask;
+XID window;
+XID resource;
+struct list entry;
+};
+
+
+
struct PointerBarrier {
+XIDbarrier;
CARD16 x1, x2, y1, y2;
CARD32 directions;
+CARD32 velocity;
+CARD32 barrierEventID;
+CARD32 releaseEventID;
+Bool hit, lastHit;
};
diff --git a/xfixes/xfixesint.h b/xfixes/xfixesint.h
index 6ba276e..cb00be6 100644
--- a/xfixes/xfixesint.h
+++ b/xfixes/xfixesint.h
@@ -59,6 +59,7 @@
#include windowstr.h
#include selection.h
#include xfixes.h
+#include list.h
extern int XFixesEventBase;
@@ -293,6 +294,26 @@ ProcXFixesDestroyPointerBarrier (ClientPtr client);
int
SProcXFixesDestroyPointerBarrier (ClientPtr client);
+/* Version 6 */
+
+int
+ProcXFixesSelectBarrierInput (ClientPtr client);
+
+int
+SProcXFixesSelectBarrierInput (ClientPtr client);
+
+int
+ProcXFixesCreatePointerBarrierVelocity (ClientPtr client);
+
+int
+SProcXFixesCreatePointerBarrierVelocity (ClientPtr client);
+
+int
+ProcXFixesBarrierReleasePointer (ClientPtr client);
+
+int
+SProcXFixesBarrierReleasePointer (ClientPtr client);
+
/* Xinerama */
extern int (*PanoramiXSaveXFixesVector[XFixesNumberRequests])(ClientPtr);
void PanoramiXFixesInit (void);
diff --git a/debian/changelog b/debian/changelog
index ee46d5f..3b6baa2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+libxfixes (1:5.0-6~hacking2) precise; urgency=low
+
+ * Hook up event-id BarrierReleasePointer
+
+ -- Christopher James Halse Rogers r...@ubuntu.com Wed, 25 Jan 2012 14:42:06 +1100
+
+libxfixes (1:5.0-6~hacking1) precise; urgency=low
+
+ * More and different thresholding
+
+ -- Christopher James Halse Rogers r...@ubuntu.com Wed, 25 Jan 2012 11:56:16 +1100
+
+libxfixes (1:5.0-5) precise; urgency=low
+
+ * Pointer-barrier-thresholding
+
+ -- Christopher James Halse Rogers r...@ubuntu.com Wed, 18 Jan 2012 22:09:44 +1100
+
libxfixes (1:5.0-4) unstable; urgency=low
* Team upload.
diff --git a/debian/control b/debian/control
index a507388..dc27cb8 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends:
debhelper (= 8.1.3),
dh-autoreconf,
libx11-dev (= 2:1.3.3-2),
- x11proto-fixes-dev (= 1:5.0),
+ x11proto-fixes-dev (= 1:5.0-5~hacking2~),
pkg-config,
quilt,
xutils-dev (= 1:7.5+4),
diff --git a/debian/libxfixes3.symbols b/debian/libxfixes3.symbols
index 2cedbeb..7f2eabc 100644
--- a/debian/libxfixes3.symbols
+++ b/debian/libxfixes3.symbols
@@ -1,9 +1,11 @@
libXfixes.so.3 libxfixes3 #MINVER#
+ XFixesBarrierReleasePointer@Base 1:5.0-5~hacking2
XFixesChangeCursor@Base 0
XFixesChangeCursorByName@Base 0
XFixesChangeSaveSet@Base 0
XFixesCopyRegion@Base 0
XFixesCreatePointerBarrier@Base 1:5.0
+ XFixesCreatePointerBarrierVelocity@Base 1:5.0-4
XFixesCreateRegion@Base 0
XFixesCreateRegionFromBitmap@Base 0
XFixesCreateRegionFromGC@Base 0
@@ -25,6 +27,7 @@ libXfixes.so.3 libxfixes3 #MINVER#
XFixesQueryExtension@Base 0
XFixesQueryVersion@Base 0
XFixesRegionExtents@Base 0
+ XFixesSelectBarrierInput@Base 1:5.0-4
XFixesSelectCursorInput@Base 0
XFixesSelectSelectionInput@Base 0
XFixesSetCursorName@Base 0
diff --git a/include/X11/extensions/Xfixes.h b/include/X11/extensions/Xfixes.h
index 10a7e2e..9b1e03a 100644
--- a/include/X11/extensions/Xfixes.h
+++ b/include/X11/extensions/Xfixes.h
@@ -259,11 +259,48 @@ XFixesCreatePointerBarrier(Display *dpy, Window w, int x1, int y1,
int x2, int y2, int directions,
int num_devices, int *devices);
+PointerBarrier
+XFixesCreatePointerBarrierVelocity(Display *dpy, Window w, int x1, int y1,
+ int x2, int y2, int directions, int velocity,
+ int num_devices, int *devices);
+
void
XFixesDestroyPointerBarrier(Display *dpy, PointerBarrier b);
#endif /* XFIXES_MAJOR = 5 */
+#if XFIXES_MAJOR = 6
+
+typedef int32_t BarrierEventID;
+
+typedef struct {
+int type; /* event base */
+int subtype;
+unsigned long serial;
+Bool send_event;
+Display *display;
+Window window;
+BarrierEventID event_id;
+int directions;
+PointerBarrier barrier;
+int x;
+int y;
+int velocity;
+Time timestamp;
+} XFixesBarrierNotifyEvent;
+
+void
+XFixesSelectBarrierInput (Display *dpy,
+ Window win,
+ unsigned long eventMask);
+
+void
+XFixesBarrierReleasePointer(Display *dpy,
+ PointerBarrier b,
+ BarrierEventID event_id);
+
+#endif
+
_XFUNCPROTOEND
#endif /* _XFIXES_H_ */
diff --git a/src/Cursor.c b/src/Cursor.c
index 0d656f7..e04422d 100644
--- a/src/Cursor.c
+++ b/src/Cursor.c
@@ -334,3 +334,84 @@ XFixesDestroyPointerBarrier(Display *dpy, PointerBarrier b)
UnlockDisplay (dpy);
SyncHandle
[RFC PATCH v3] fixesproto v6: Pointer barrier improvements.
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
Adds a velocity-gated pointer barrier, events to notify a client when barriers
are hit, and a mechanism for clients to temporarily allow movement through
a barrier.
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
Whoops. git-fail.
Here's the *actual* simplified protocol those patches implement, and that
we've found to be sufficiently useful.
fixesproto.txt | 87
xfixesproto.h | 57
xfixeswire.h | 23 --
3 files changed, 163 insertions(+), 4 deletions(-)
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..1f4fa3e 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,93 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierEvent: {Hit, ThresholdExceeded}
+ BarrierEventID: CARD32
+
+13.2 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ event-id: BarrierEventID
+ barrier:BARRIER
+ timestamp: Timestamp
+ velocity: CARD32
+ x, y: INT16
+
+13.3 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered. (x,y) contain
+ the coordinates of the pointer after restriction by any applicable
+ barriers, and velocity is the unrestricted instantaneous velocity
+ of the pointer perpendicular to the barrier.
+
+ event-id is an identifier for this barrier event. A barrier event
+ begins when the pointer is first restricted by the barrier, and ends
+ with the first mouse event that is not restricted by the barrier.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreatePointerBarrierVelocity
+
+ barrier:BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ threshold: CARD32
+ devices:LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. This
+ has identical semantics to CreatePointerBarrier, except that the
+ barrier created will not block the pointer if the threshold
+ velocity is exceeded. The velocity is measured in px/sec perpendicular
+ to the barrier.
+
+ Once the pointer has been stopped by the barrier it will remain blocked
+ for the duration of the barrier event.
+
+ Errors: IDChoice, Window, Value, Device
+
+BarrierReleasePointer
+
+ barrier:BARRIER
+ event-id: BarrierEventID
+
+ Temporarily allow the pointer to pass through a pointer barrier.
+ This disables the barrier for as long as event-id is valid - that is,
+ as long as the pointer remains in contact with the barrier.
+
+ Requests to release the pointer for an event-id which is not current
+ are silently ignored.
+
+ Errors: Barrier
+
+
99. Future compatibility
This extension is not expected to remain fixed. Future changes will
diff --git a/xfixesproto.h b/xfixesproto.h
index fcf409a..9189c19 100644
--- a/xfixesproto.h
+++ b/xfixesproto.h
@@ -532,6 +532,63 @@ typedef struct {
#define sz_xXFixesDestroyPointerBarrierReq 8
+/*** Version 6.0 **/
+
+#define BarrierEventID CARD32
+
+typedef struct {
+ CARD8 type;
+ CARD8 subtype;
+ CARD16 sequenceNumber B16;
+ Window window; B32;
+ BarrierEventID event_id B32;
+ Barrier barrier;
+ Timetimestamp B32;
+ CARD32 velocity B32;
+ INT16 x B16;
+ INT16 y B16;
+} xXFixesBarrierNotifyEvent;
+
+typedef struct {
+CARD8 reqType
[PATCH] fixesproto v6: Pointer barrier thresholds
From: Christopher James Halse Rogers christopher.halse.rog...@canonical.com
---
This is prompted by a request from the Ubuntu DX team to conditionally restrict
pointer motion at a screen edge. The Unity launcher appears on a screen edge,
triggered by pointer proximity, and the objective is to have a form of edge
resistance so that it is easy to summon the launcher on the border of two
displays while still allowing determined pointer motion through.
There doesn't seem to be a good way to implement this client-side. Pointer
barriers seem the obvious mechanism, but turning them on and off runs
into roundtrip latency, and there's some useful information that the server
has that's not easily available to a client.
This is the second go at a protocol. The first simply added a velocity-gated
pointer barrier request. In testing this suboptimal behaviour - getting the
pointer past the barrier required too vigourous a motion, and it was desired
that the barrier would also respond to a period of gentler motion in addition
to being transparent to sufficiently fast movement.
I'm aware that this is becoming a bit elaborate. I'd like some guidance -
I don't want to make something that's pointlessly generic, but it should be
useful outside of Unity's specific usecase.
fixesproto.txt | 118
1 files changed, 118 insertions(+), 0 deletions(-)
diff --git a/fixesproto.txt b/fixesproto.txt
index 5903ac9..16a7aae 100644
--- a/fixesproto.txt
+++ b/fixesproto.txt
@@ -650,6 +650,124 @@ DestroyPointerBarrier
Errors: Barrier
+* XFIXES VERSION 6 OR BETTER ***
+
+13. Pointer Barriers Expansion
+
+This update extends pointer barriers to optionally allow the pointer through
+when a threshold is reached. This can be useful for desktop environments that
+wish to use a large region of the screen, such as an entire edge, to provide a
+casual target while allowing determined movement to pass through.
+
+13.1 Types
+
+ BarrierThreshold: XID
+ BarrierThresholdKind: {None, Distance, Velocity, HitCount}
+ BarrierEvent: {Hit, ThresholdExceeded}
+
+13.2 Errors
+
+ BarrierThreshold
+
+13.3 Events
+
+BarrierNotify
+
+ subtype:BarrierEvent
+ window: WINDOW
+ timestamp: Timestamp
+ barrier:BARRIER
+ threshold: BARRIERTHRESHOLD or None
+ value: CARD32
+ x, y: INT16
+
+13.4 Requests
+
+SelectBarrierInput
+
+ window: WINDOW
+ event-mask: SETofBarrierEvent
+
+
+ This request directs barrier events to the named window. Subtype
+ indicates the trigger of the event, which is Hit when the barrier has
+ prevented pointer movement and ThresholdExceeded when the barrier has
+ been hit but has not prevented pointer movement due to the threshold
+ being exceeded.
+
+ Barrier is the barrier on which the event was triggered, which is
+ associated with threshold or None if no threshold is associated.
+ If threshold is not None, value contains the current value of the
+ property the threshold measures against.
+
+ (x,y) contain the coordinates of the pointer after restriction by any
+ applicable barriers.
+
+ In the case of multiple overlapping barriers an event is sent for each.
+
+CreateBarrierThreshold
+
+ threshold: BARRIERTHRESHOLD
+ type: BarrierThresholdKind
+ value: CARD32
+
+ This request creates a new barrier threshold. This threshold
+ specifies a condition under which a pointer barrier will allow a
+ pointer to pass through unimpeded.
+
+ Type can be None, in which case the threshold is never triggered.
+
+ Type can be Distance, in which case the threshold will trigger if the
+ user attempts to move the pointer a cumulative distance in px greater
+ than value. The distance is not automatically reset, so once the
+ threshold has been triggered it will remain triggered.
+
+ Type can be Velocity, in which case the threshold will trigger if the
+ instantaneous velocity of the pointer, perpendicular to the barrier,
+ in px/sec is greater than value.
+
+ Type can be HitCount, in which case the threshold will trigger once the
+ barrier has been hit value times. The count is not automatically
+ reset, so once the threshold has been triggered it will remain
+ triggered.
+
+ If type is not one of these values, BadValue is generated.
+
+ Errors: IDChoice, Value
+
+AddBarrierThresholdOr
+AddBarrierThresholdAnd
+
+ threshold
