On 18/11/15 06:59 PM, Peter Hutterer wrote: > On Tue, Nov 17, 2015 at 06:09:18PM +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> >> --- >> >> Changes since last version sent as weston patches: >> >> Interfaces and protocol renamed according to wayland-protocols naming >> conventions. >> >> The global interface is now called wl_pointer_constraints instead of >> wl_pointer_lock. >> >> The position hint is now double buffered. >> >> Various other minor changes. >> >> >> Jonas >> >> >> Makefile.am | 1 + >> unstable/pointer-constraints/README | 4 + >> .../pointer-constraints-unstable-v1.xml | 283 >> +++++++++++++++++++++ >> 3 files changed, 288 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 2db6bd5..983ae1b 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -6,6 +6,7 @@ nobase_dist_pkgdata_DATA = >> \ >> 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) >> >> pkgconfigdir = $(libdir)/pkgconfig >> 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..c71d6d5 >> --- /dev/null >> +++ b/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml >> @@ -0,0 +1,283 @@ >> +<?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> >> + >> + <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 creates the objects >> wp_locked_pointer > > typo: create > and either skip "The" or use "The ... requests" > >> + 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. >> + >> + 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> >> + >> + <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 aleady requested on that surface"/>
Typo: aleady -> already >> + </enum> >> + >> + <request name="lock_pointer"> >> + <description summary="lock pointer to a position"> >> + The lock_pointer request lets the client disable absolute pointer >> + movements, locking the pointer to a position. 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. > > typo: implementation-specific > > wording: "absolute pointer movements" is ambiguous since we disable both > relative and absolute movements, only wl_relative_pointer isn't affected. > How about: > "...disables movements of the virtual pointer (i.e. the cursor), > effectively locking the pointer to a position." > > followed by a "This request may not take effect immediately. Int the > future..." > >> + >> + 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 when requesting a lock, and if there is, an error > > s/, and if/. If/ > >> + will be raised. See general pointer lock documentation for more details. >> + >> + 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 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. > > "whether to warp the pointer or require..." > >> + >> + 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 >> + 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 motion events, but relative motion > > I would explicitly state wl_pointer.motion events here, to avoid any > potential ambiguity. And add that axis and button events are unaffected. > >> + events will still be emitted via wp_relative_pointer objects of the >> + same seat. >> + </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="seat" type="object" interface="wl_seat" >> + summary="seat where the pointer should be locked"/> >> + <arg name="region" type="object" interface="wl_region" >> allow-null="true" >> + summary="region of surface"/> >> + </request> >> + >> + <request name="confine_pointer"> >> + <description summary="confine pointer to a region"> >> + The confine_pointer request lets the client confine the pointer cursor >> + to a given region. > > add the same blurb with "no immediate effect, in the future, blah" > >> + >> + 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 to >> + warp the pointer, or require some kind of user interaction for the > > "whether to warp the pointer or require some..." > > >> + 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="seat" type="object" interface="wl_seat" >> + summary="seat where the pointer should be locked"/> >> + <arg name="region" type="object" interface="wl_region" >> allow-null="true" >> + summary="region of surface"/> >> + </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 motion events. > > wl_pointer.motion > >> + >> + 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. >> + >> + When unlocking, the compositor may take the cursor position pointer. >> If > > s/pointer pointer/pointer hint/ > >> + it does, it will not result in any relative motion events emitted via >> + wp_relative_pointer. >> + >> + If the surface lock was requested on is destroyed and the lock is not >> yet > > "the lock was requested on" > >> + 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. The compositor will unlock the >> + pointer. > > "If applicable, the compositor will..." > >> + </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. >> + >> + The new region has no effect on a lock that has already been activated. >> + >> + 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 this seat's pointer is activated. >> + </description> >> + </event> >> + >> + <event name="unlocked"> >> + <description summary="lock deactivation event"> >> + Notification that the pointer lock of seat's pointer is no longer >> + active. This object is now defunct and should be destroyed. >> + </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. The compositor will unconfine the >> + pointer. > > "If applicable, ..." > > All these are typos only, the protocol looks good > Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net> > > Cheers, > Peter > >> + </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. >> + >> + 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="enter event"> >> + Notification that the pointer confinement of this seat's pointer is >> + activated. >> + </description> >> + </event> >> + >> + <event name="unconfined"> >> + <description summary="leave event"> Seems odd to summarize these descriptions with "enter" and "leave" to me. Otherwise, I have no comments Peter didn't already make, and the protocol seems solid to me. Reviewed-by: Derek Foreman <der...@osg.samsung.com> >> + Notification that the pointer confinement of seat's pointer is no >> + longer active. This object is no defunct and should be destroyed. >> + </description> >> + </event> >> + </interface> >> + >> +</protocol> >> -- >> 2.4.3 > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
