[PATCH weston 0/3] Pointer locking revisited

[Axel Davy]

On 17/09/2014 21:39, Jonas Ådahl wrote :
> Hi,
>
> This short series introduces a pointer lock interface based on the
> previous proposal[0] by Kristian Høgsberg from last year. The first patch
> adds a protocol more or less equal to Kristians proposal, but moved out
> of wl_seat into its own global object (currently _wl_pointer_lock), with
> some concerns raised in the original thread addressed. The implementation
> in weston is new. There was no point trying to rebase the previous
> implementation due to the architectural changes done since that patch was
> written.
>
> The second patch introduces a client side API in toytoolkit, and the
> forth makes use of that API in resizor, in the same way as in the
> previous proposal, to resize its window.
>
> Note that the reason for having the underscore prefix is to have the
> possibility to push a stable variant to the wayland repo without
> breaking any clients implementing the experimental version. The
> intention is that _wl_pointer_lock ever would be considered an
> official interface, it would be renamed to wl_pointer_lock.
>
> In short, the interface works by having the client create a separate
> wl_pointer object, using wl_pointer_lock.lock_pointer, that gets focus
> until wl_pointer.release is requested and the surface gets deactivated.
> If the locked pointer object is still not released when a surface
> is activated again, the pointer will be implicitly locked to the special
> wl_pointer object again.
>
> Limitations with this approach include that it would, as far as I know,
> not be possible to fully implement pointer warping support in Xwayland
> only using this protocol. However, not sure if support for legacy
> concepts is within the scope of an interface like this. Maybe Xwayland
> needs some private way to communicate (privileged wl_xwayland interface?)
> for these type of things? Maybe it could be emulated by locking if
> warping is done with some heuristic for releasing the lock, but have not
> tried to implement that.
>
> We wouldn't be able to implement API of certain toolkits (for example
> SDL, GLFW). This I suppose is not really a big deal as it wouldn't be the
> first (global positions etc) and the use case is most likely to lock the
> pointer and get relative motion events, and there is API available in
> both those toolkits for that. Pointer confinement (absolute motion
> events, but not letting the pointer leave the surface) is another
> functionality that wouldn't be possible. It could be emulated by having
> the client lock the pointer and draw the pointer itself given the
> relative motion events, or simply added to this protocol in some way
> (wl_pointer_lock.confine_pointer?).
>
> In the previous thread, surface transformations came up as something that
> needed to be thought through. In the updated protocol of this series, I
> clarified that relative motion events are as if the surface has not been,
> transformed. The reasoning behind this is more or less how typical use
> case looks like: 1:st person 3D games. I would expect that the viewport
> moves the same even if the window happen to have been transformed for
> example zoomed or rotated.
>
> Following the trend of keeping track of these kind of stuff, I filed[1] a
> bug on BZ as well.
>
> Thoughts? Is this the right way to go?
>
>
> Jonas
>
> [0] http://lists.freedesktop.org/archives/wayland-devel/2013-February/007635.html
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=84014
>
> Jonas Ådahl (3):
>    Introduce pointer lock interface
>    clients: Introduce pointer lock API to toytoolkit
>    resizor: Make resizor also use pointer locks for resizing
>
>   Makefile.am               |  11 +-
>   clients/resizor.c         |  62 +++++++++++
>   clients/window.c          | 177 +++++++++++++++++++++++++++++
>   clients/window.h          |  42 +++++++
>   desktop-shell/exposay.c   |   2 +-
>   desktop-shell/shell.c     |  10 +-
>   protocol/pointer-lock.xml |  85 ++++++++++++++
>   src/compositor.c          |   4 +
>   src/compositor.h          |  21 +++-
>   src/input.c               | 277 +++++++++++++++++++++++++++++++++++++++++++++-
>   10 files changed, 678 insertions(+), 13 deletions(-)
>   create mode 100644 protocol/pointer-lock.xml
>
Thanks for getting into this.

Could you clarify where the cursor should be during the lock,
and what should be the cursor position when a lock is ended ?

Axel Davy