[PATCH weston 0/3] Pointer locking revisited
axel.davy at ens.fr
Wed Sep 17 12:55:36 PDT 2014
On 17/09/2014 21:39, Jonas Ådahl wrote :
> This short series introduces a pointer lock interface based on the
> previous proposal 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
> 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
> 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 a
> bug on BZ as well.
> Thoughts? Is this the right way to go?
>  http://lists.freedesktop.org/archives/wayland-devel/2013-February/007635.html
>  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 ?
More information about the wayland-devel