On Wed, Jan 13, 2016 at 10:14:50AM +0800, Jonas Ådahl wrote: > This patch introduces a new protocol for locking and confining a > pointer. It consists of a new global object with two requests; one for > locking the surface to a position, one for confining the pointer to a > given region. > > Signed-off-by: Jonas Ådahl <jad...@gmail.com> > Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> > Reviewed-by: Derek Foreman <der...@osg.samsung.com> > --- > > Changes since v2: > > Added a "lifetime" enum which is passed to the locking/confining requests. It > is used to specify whether the constraints should be oneshot or reoccurring. > Oneshot and reoccurring both has race conditions when they are deactivated, > and > this enables the client to choose what race condition it prefers. > > The oneshot race condition is that client may not be able to re-request the > constraint in time, and as a result will loose the constraint where it should > not have. > > The reoccurring race condition is that the client may not be able to destroy > the constraint in time, and as a result the compositor will re-constrain the > pointer when it shouldn't. > > Whether each of these race conditions are preferrable depends on the > application using them, so lets give the client the option to choose. > > > Another change is that the factory requests now take a wl_pointer instead of a > wl_seat. > > > Jonas > > > Makefile.am | 1 + > unstable/pointer-constraints/README | 4 + > .../pointer-constraints-unstable-v1.xml | 341 > +++++++++++++++++++++ > 3 files changed, 346 insertions(+) > create mode 100644 unstable/pointer-constraints/README > create mode 100644 > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index e3b60ad..44041a6 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -6,6 +6,7 @@ unstable_protocols = > \ > unstable/input-method/input-method-unstable-v1.xml > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > + unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > $(NULL) > > nobase_dist_pkgdata_DATA = > \ > diff --git a/unstable/pointer-constraints/README > b/unstable/pointer-constraints/README > new file mode 100644 > index 0000000..8a242f8 > --- /dev/null > +++ b/unstable/pointer-constraints/README > @@ -0,0 +1,4 @@ > +Pointer constraints protocol > + > +Maintainers: > +Jonas Ådahl <jad...@gmail.com> > diff --git a/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > new file mode 100644 > index 0000000..607a538 > --- /dev/null > +++ b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > @@ -0,0 +1,341 @@ > +<?xml version="1.0" encoding="UTF-8"?> > +<protocol name="pointer_constraints_unstable_v1"> > + > + <copyright> > + Copyright © 2014 Jonas Ådahl > + Copyright © 2015 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> > + > + <description summary="Protocol for constraining pointer motions"> > + This protocol specifies a set of interfaces used for adding constraints > to > + the motion of a pointer. Possible constraints include confining pointer > + motions to a given region, or locking it to its current position. > + > + In order to contrain the pointer, a client must first bind the global > + interface "wp_pointer_constraints" which, if a compositor supports > pointer > + constraints, is exposed by the registry. Using the bound global object, > the > + client uses the request that corresponds to the type of constraint it > wants > + to make. See wp_pointer_constraints for more details. > + > + Warning! The protocol described in this file is experimental and backward > + incompatible changes may be made. Backward compatible changes may be > added > + together with the corresponding interface version bump. Backward > + incompatible changes are done by bumping the version number in the > protocol > + and interface names and resetting the interface version. Once the > protocol > + is to be declared stable, the 'z' prefix and the version number in the > + protocol and interface names are removed and the interface version > number is > + reset. > + </description> > + > + <interface name="zwp_pointer_constraints_v1" version="1"> > + <description summary="constrain the movement of a pointer"> > + The global interface exposing pointer constraining functionality. It > + exposes two requests; lock_pointer for locking the pointer to its > + position, and confine_pointer for locking the pointer to a region. > + > + The lock_pointer and confine_pointer requests create the objects > + wp_locked_pointer and wp_confined_pointer respectively, and the client > can > + use these objects to interact with the lock. > + > + For any surface, only one lock or confinement per seat may be active at > + any time. If a lock or confinement is requested when another lock or > + confinement is active or requested on that surface and seat, an > + 'already_constrained' error will be raised.
should this read as "pointer" instead of seat now? > + </description> > + > + <enum name="error"> > + <description summary="wp_pointer_constraints error values"> > + These errors can be emitted in response to wp_pointer_constraints > + requests. > + </description> > + <entry name="already_constrained" value="1" > + summary="pointer constraint already requested on that surface"/> > + </enum> > + > + <enum name="lifetime"> > + <description summary="constraint lifetime"> > + These values represent different lifetime semantics. They are passed > + as argument to the factory requests to specify how the constraint > + lifetimes should be managed. > + </description> > + <entry name="oneshot" value="1"> > + <description summary="the pointer constraint is defunct once > deactivated"> > + A oneshot pointer constraint will never re-activate once it has been > + deactivated. See the corresponding deactivation event > + (wp_locked_pointer.unlocked and wp_confined_pointer.unconfined) for > + details. > + </description> > + </entry> > + <entry name="reoccurring" value="2"> drop the 'o', this should be "recurring", goes for all uses of the word below. > + <description summary="the pointer constraint is defunct once > deactivated"> and this should be a bit different to the oneshot :) > + A reoccurring pointer constraint may again re-activate once it has > + been deactivated. See the corresponding deactivation event if deactivate doesn't get a -, reactivate shouldn't either. > + (wp_locked_pointer.unlocked and wp_confined_pointer.unconfined) for > + details. > + </description> > + </entry> > + </enum> > + > + <request name="destroy" type="destructor"> > + <description summary="destroy the pointer constraints manager object"> > + Used by the client to notify the server that it will no longer use this > + pointer constraints object. > + </description> > + </request> > + > + <request name="lock_pointer"> > + <description summary="lock pointer to a position"> > + The lock_pointer request lets the client request to disable movements of > + the virtual pointer (i.e. the cursor), effectively locking the pointer > + to a position. This request may not take effect immediately; in the > + future, when the compositor deems implementation-specific constraints > + are satisfied, the pointer lock will be activated and the compositor > + sends a locked event. > + > + The protocol provides no guarantee that the constraints are ever > + satisfied, and does not require the compositor to send an error if the > + constraints cannot ever be satisfied. It is thus possible to request a > + lock that will never activate. > + > + There may not be another lock of any kind requested or active on the > + surface for the seat of the given pointer when requesting a lock. If > + there is, an error will be raised. See general pointer lock > + documentation for more details. needs a seat/pointer rewording > + > + The intersection of the region passed with this request and the input > + region of the surface is used to determine where the pointer must be > + in order for the lock to activate. It is up to the compositor whether to > + warp the pointer or require some kind of user interaction for the lock > + to activate. If the region is null the surface input region is used. > + > + A surface may receive pointer focus without the lock being activated. > + > + The request will create a new object wp_locked_pointer which is used to s/will create/creates/ > + interact with the lock as well as receive updates about its state. See > + the the description of wp_locked_pointer for further information. > + > + Note that while a pointer is locked, the wl_pointer objects of the > + corresponding seat will not emit any wl_pointer.motion events, but > + relative motion events will still be emitted via wp_relative_pointer > + objects of the same seat. wl_pointer.axis and wl_pointer.button events > + are unaffected. > + </description> > + > + <arg name="id" type="new_id" interface="zwp_locked_pointer_v1"/> > + <arg name="surface" type="object" interface="wl_surface" > + summary="surface to lock pointer to"/> > + <arg name="pointer" type="object" interface="wl_pointer" > + summary="the pointer that should be locked"/> > + <arg name="region" type="object" interface="wl_region" > allow-null="true" > + summary="region of surface"/> > + <arg name="lifetime" type="uint" summary="lock lifetime"/> > + </request> > + > + <request name="confine_pointer"> > + <description summary="confine pointer to a region"> > + The confine_pointer request lets the client request to confine the > + pointer cursor to a given region. This request may not take effect > + immediately; in the future, when the compositor deems implementation- > + specific constraints are satisfied, the pointer confinement will be > + activated and the compositor sends a confined event. > + > + The intersection of the region passed with this request and the input > + region of the surface is used to determine where the pointer must be > + in order for the confinement to activate. It is up to the compositor > + whether to warp the pointer or require some kind of user interaction for > + the confinement to activate. If the region is null the surface input > + region is used. > + > + The request will create a new object wp_confined_pointer which is used > + to interact with the confinement as well as receive updates about its > + state. See the the description of wp_confined_pointer for further > + information. > + </description> > + > + <arg name="id" type="new_id" interface="zwp_confined_pointer_v1"/> > + <arg name="surface" type="object" interface="wl_surface" > + summary="surface to lock pointer to"/> > + <arg name="pointer" type="object" interface="wl_pointer" > + summary="the pointer that should be confined"/> > + <arg name="region" type="object" interface="wl_region" > allow-null="true" > + summary="region of surface"/> > + <arg name="lifetime" type="uint" summary="confinement lifetime"/> > + </request> > + </interface> > + > + <interface name="zwp_locked_pointer_v1" version="1"> > + <description summary="receive relative pointer motion events"> > + The wp_locked_pointer interface represents a locked pointer state. > + > + While the lock of this object is active, the wl_pointer objects of the > + associated seat will not emit any wl_pointer.motion events. > + > + This object will send the event 'locked' when the lock is activated. > + Whenever the lock is activated, it is guaranteed that the locked > surface > + will already have received pointer focus and that the pointer will be > + within the region passed to the request creating this object. > + > + To unlock the pointer, send the destroy request. This will also destroy > + the wp_locked_pointer object. > + > + If the compositor decides to unlock the pointer the unlocked event is > + sent. The wp_locked_pointer object is at this point defunct and should > be > + destroyed. needs updates for the lifetime, or just a reference to the unlocked event documentation. > + > + When unlocking, the compositor may warp the cursor position to the set > + cursor position hint. If it does, it will not result in any relative > + motion events emitted via wp_relative_pointer. > + > + If the surface the lock was requested on is destroyed and the lock is > not > + yet activated, the wp_locked_pointer object is now defunct and must be > + destroyed. > + </description> > + > + <request name="destroy" type="destructor"> > + <description summary="destroy the locked pointer object"> > + Destroy the locked pointer object. If applicable, the compositor will > + unlock the pointer. > + </description> > + </request> > + > + <request name="set_cursor_position_hint"> > + <description summary="set the pointer cursor position hint"> > + Set the cursor position hint relative to the top left corner of the > + surface. > + > + If the client is drawing its own cursor, it should update the position > + hint to the position of its own cursor. A compositor may use this > + information to warp the pointer upon unlock in order to avoid pointer > + jumps. > + > + The cursor position hint is double buffered. The new hint will only take > + effect when the associated surface gets it pending state applied. See > + wl_surface.commit for details. > + </description> > + > + <arg name="surface_x" type="fixed" > + summary="x coordinate in surface-relative coordinates"/> > + <arg name="surface_y" type="fixed" > + summary="y coordinate in surface-relative coordinates"/> > + </request> > + > + <request name="set_region"> > + <description summary="set a new lock region"> > + Set a new region used to lock the pointer. > + > + The new lock region is double-buffered. The new lock region will > + only take effect when the associated surface gets its pending state > + applied. See wl_surface.commit for details. > + > + For details about the lock region, see wp_locked_pointer. > + </description> > + > + <arg name="region" type="object" interface="wl_region" > allow-null="true" > + summary="region of surface"/> > + </request> > + > + <event name="locked"> > + <description summary="lock activation event"> > + Notification that the pointer lock of the seat's pointer is activated. > + </description> > + </event> > + > + <event name="unlocked"> > + <description summary="lock deactivation event"> > + Notification that the pointer lock of the seat's pointer is no longer > + active. If this is a oneshot pointer lock (see > + wp_pointer_constraints.lifetime) this object is now defunct and should > + be destroyed. If this is a reoccurring pointer lock (see > + wp_pointer_constraints.lifetime) this the pointer lock may again > + reactivate in the future. > + </description> > + </event> > + </interface> > + > + <interface name="zwp_confined_pointer_v1" version="1"> > + <description summary="confined pointer object"> > + The wp_confined_pointer interface represents a confined pointer state. > + > + This object will send the event 'confined' when the confinement is > + activated. Whenever the confinement is activated, it is guaranteed that > + the surface the pointer is confined to will already have received > pointer > + focus and that the pointer will be within the region passed to the > request > + creating this object. It is up to the compositor to decide whether this > + requires some user interaction and if the pointer will warp to within > the > + passed region if outside. > + > + To unconfine the pointer, send the destroy request. This will also > destroy > + the wp_confined_pointer object. > + > + If the compositor decides to unconfine the pointer the unconfined > event is > + sent. The wp_confined_pointer object is at this point defunct and > should > + be destroyed. > + </description> > + > + <request name="destroy" type="destructor"> > + <description summary="destroy the confined pointer object"> > + Destroy the confined pointer object. If applicable, the compositor will > + unconfine the pointer. > + </description> > + </request> > + > + <request name="set_region"> > + <description summary="set a new confine region"> > + Set a new region used to confine the pointer. > + > + The new confine region is double-buffered. The new confine region will > + only take effect when the associated surface gets its pending state > + applied. See wl_surface.commit for details. > + > + If the confinement is active when the new confinement region is applied > + and the pointer ends up outside of newly applied region, the pointer is > + warped to a position within the new confinement region. If warped, a > + wl_pointer.motion event will be emitted, but no > + wp_relative_pointer.relative_motion event. is there a case where the compositor will break the confinement if it's not happy with the new region? If so, we should add a comment here to state that. my rev-by still stands. Cheers, Peter > + > + For details about the confine region, see wp_confined_pointer. > + </description> > + > + <arg name="region" type="object" interface="wl_region" > allow-null="true" > + summary="region of surface"/> > + </request> > + > + <event name="confined"> > + <description summary="pointer confined"> > + Notification that the pointer confinement of the seat's pointer is > + activated. > + </description> > + </event> > + > + <event name="unconfined"> > + <description summary="pointer unconfined"> > + Notification that the pointer confinement of the seat's pointer is no > + longer active. If this is a oneshot pointer confinement (see > + wp_pointer_constraints.lifetime) this object is now defunct and should > + be destroyed. If this is a reoccurring pointer confinement (see > + wp_pointer_constraints.lifetime) this the pointer confinement may again > + reactivate in the future. > + </description> > + </event> > + </interface> > + > +</protocol> > -- > 2.4.3 > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
