[PATCH wayland-protocols 2/2] Introduce pointer locking and confinement protocol
Derek Foreman
derekf at osg.samsung.com
Mon Nov 23 13:54:07 PST 2015
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 <jadahl at 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 <jadahl at 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.hutterer at 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 <derekf at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
More information about the wayland-devel
mailing list