[PATCH weston 0/3] Pointer locking revisited

[Jonas Ådahl]

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

-- 
1.8.5.1