[PATCH weston 0/3] Pointer locking revisited

[Jonas Ådahl]

On Wed, Sep 17, 2014 at 09:55:36PM +0200, Axel Davy wrote:
> 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 ?

Sure. Can add a clause saying that the the position of the actual pointer
will stay where it was before the lock was initiated (be it by
lock_pointer or surface activation). Regarding the cursor, hiding it
during it being locked probably makes most sense.


Jonas

> 
> Axel Davy