On Wed, Jan 13, 2016 at 02:44:29PM +1000, Peter Hutterer wrote:
> 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 <[email protected]>
> > Reviewed-by: Peter Hutterer <[email protected]>
> > Reviewed-by: Derek Foreman <[email protected]>
> > ---
> >
> > 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 <[email protected]>
> > 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?
This paragraph is now changed to:
For any surface, only one lock or confinement may be active across all
wl_pointer objects of the same seat. If a lock or confinement is requested
when another lock or confinement is active or requested on the same
surface
and with any of the wl_pointer objects of the same seat, an
'already_constrained' error will be raised.
>
> > + </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.
Hmm. I guess so. What I can see about the difference between reoccurring
and recurring is that recurring means occurring again at a regular
interval, while reoccurring means maybe occurring again at an irregular
interval. So is recurring really correct?
>
> > + <description summary="the pointer constraint is defunct once
> > deactivated">
>
> and this should be a bit different to the oneshot :)
Changed to "the pointer constraint is may reactivate"
>
> > + 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.
Fixed locally.
>
> > + (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
This paragraph is now:
There may not be another pointer constraint of any kind requested or
active on the surface for any of the wl_pointer objects of the seat of
the passed pointer when requesting a lock. If there is, an error 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 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/
Fixed locally.
>
> > + 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.
Fixed by just referencing .unlocked.
>
> > +
> > + 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.
Hmm. I suppose a 0x0 region would be hard to make any sense of. I guess we can
add a blurb about that an effective 0x0 region (intersection between set region
and input region is 0x0) would result in an unconfined event.
Something like:
If the effective confinement region (the intersection of the applied
confinement region and the input region of the corresponding wl_surface)
is empty, an active confinement would be deactivated.
maybe?
>
> my rev-by still stands.
Thanks!
Jonas
>
> 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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
