[PATCH weston 00/17] Relative pointer motions, locking and confinement

Tue Dec 2 10:27:23 PST 2014

On Tue, Dec 2, 2014 at 5:49 AM, Jonas Ådahl <jadahl at gmail.com> wrote:

> Hi again,
>
> At XDC2014 some of us sat down and talked through how pointer locking
> and related protocols should look like, and this series is more or less
> work-in-progress result of that discussion.
>
> The series contains two parts (and one bonus patch). The bonus patch
> is the initial white space only patch formatting the input method
> protocols making it slightly more readable and consistent with other
> protocol files.
>
> The first part (2 - 12) is preparation for the implementation of the new
> interfaces.
>
> The second part (13 - 17) is the introduction, implementation and
> application of the new protocol interfaces.
>
> Accompanied with this series is also a patch to libinput (Introduce
> non-accelerated motion event vectors), and implementations in GLFW
> <https://github.com/jadahl/glfw/commits/pointer-lock> and SDL2
> <https://bitbucket.org/jadahl/sdl/commits/branch/pointer-lock>. In GLFW
> you can try the wave example, and for SDL, you could try for example
> ioquake3 or openarena.
>
> One of the things we concluded was that relative pointer motions should
> be treated separately from locking and confinement, so of the second
> part, patch 13 introduces the new "relative pointer" object that is an
> additional interface to the wl_pointer object. Think of it in the same
> way, as in you get it from a seat, and it emits motion events, only ones
> with relative motion deltas. One can create as many as one wants, and
> they don't interfere with each other, just as wl_pointer. It might be
> better to simply extend wl_seat when stabilizing this protocol, but it's
> put separately for testing purposes.
>
> For details of how the protocol works, please read the protocol XML file.
> In short, locking and confinement are two "locking" modes, of which one
> may only be active at once. From the discussions, there is one difference
> I can think of and that is that locking/confining an already
> locked/confined pointer is invalid, instead of queued, as it simplified
> the implementation quite a lot, and I think for most cases unlocking and
> then locking again will work good enough. For the cases where such a
> scenario would break the lock and fail to relock, we could for example
> change the heuristics the compositor applies to get a better behavior,
> without making the interface more complex. Please tell if you think
> queued locking is indeed needed.
>

Yeah, I think this is probably ok.  And you're right that it simplifies
things substantially.  It should be easy enough for compositors to add a
little heuristic to make it practical.  Let's see how this goes and I think
we can probably deal with it later if we want.

>
> One thing of the specification is currently not fully implemented as
> there are some semantical choices that needs to be made and specified
> before it makes sense to go forward, and that is how to deal with non
> rectangular locking regions. The current implementation will simply never
> lock when the union of the input region and the locking region is a non
> rectangular region. The semantical ambiguity is how to treat motion
> vectors that cross corners or other borders. Consider the following
> ASCII art examples:
>
>      -------                  -------
>      |   ^ |                  |   ^ |
>      |    \|                  |    \|
>      |     |                  |  ----
>      |     ----------   or    |  -------------
>      |       \      |         |       \      |
>      |        \     |         |        \     |
>      ----------------         ----------------
>
> Simply clamping as done where there is no corners or anything would be
> result in:
>
>      -------                 -------
>      |     |                 |     |
>      |     |                 |     |
>      |     |                 |  ----
>      |     ----------  or    |  -------------
>      |   ^          |        |   ^          |
>      |    \----     |        |    \----     |
>      ----------------        ----------------
>
> Should these kind of clamping take place or not, or should they be done
> some other way? Naturally, only clamping to a rectangle is the simplest
> non-ambiguous way to go and we could simply say that locking is to the
> largest rectangle within the union of the locking region and the input
> region, but as input regions can be split, we'd have to deal with that
> situation as well. Any ideas of the preferable way to deal with the
> locking regions?
>

First off, I don't think we want to specify this in the protocol.  That
would be insane.  If the client wants it to be particularly predictable, it
should use a rectangle.  If the client gives a more complex region, It gets
what it gets.  However, we do need to restrict to the region (that's the
point of a confinement) so we can't just take the extents.

With that out of the way, I'm not sure what algorithm would be best to
use.  Basically what we're doing is collision detection and there several
algorithms for doing that reasonably efficiently.

>
>
> Jonas
>
>
> Jonas Ådahl (17):
>   protocol: Improve formatting of input method and text protocols
>   input: Pass axis events through pointer grab interfaces
>   input: Make pointer grab motion callbacks take an event struct
>   desktop-shell: Add unset_keyboard_focus_for_surface helper
>   desktop-shell: Clean up set_minimized a bit
>   desktop-shell: Make activate_binding take a view instead of surface
>   desktop-shell: Track the black surface by its view
>   desktop-shell: Change switcher to track views
>   desktop-shell: Make activate() take a view instead of surface
>   desktop-shell: Pass a flag bitmask instead of bool to activate()
>   compositor: Keep track of what views were activated by clicking
>   libinput: Expose unaccelerated motion deltas in motion event struct
>   Introduce wl_relative_pointer interface
>   Introduce pointer locking and confinement protocol
>   clients: Add API for pointer locking and pointer confinement
>   clients/resizor: Use pointer locking for resizing window
>   clients/clickdot: Use pointer confinement to confine drawed line
>
>  Makefile.am                   |  16 +-
>  clients/clickdot.c            |  32 +-
>  clients/resizor.c             | 159 +++++++-
>  clients/window.c              | 294 +++++++++++++++
>  clients/window.h              |  62 ++++
>  desktop-shell/exposay.c       |  24 +-
>  desktop-shell/shell.c         | 200 ++++++----
>  desktop-shell/shell.h         |   4 +-
>  protocol/input-method.xml     |  28 +-
>  protocol/pointer-lock.xml     | 208 +++++++++++
>  protocol/relative-pointer.xml |  90 +++++
>  protocol/text.xml             |  30 ++
>  src/compositor-x11.c          |  13 +-
>  src/compositor.c              |   9 +
>  src/compositor.h              |  71 +++-
>  src/data-device.c             |  11 +-
>  src/input.c                   | 836
> ++++++++++++++++++++++++++++++++++++++++--
>  src/libinput-device.c         |  20 +-
>  tests/weston-test.c           |  11 +-
>  19 files changed, 1971 insertions(+), 147 deletions(-)
>  create mode 100644 protocol/pointer-lock.xml
>  create mode 100644 protocol/relative-pointer.xml
>
> --
> 1.8.5.1
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141202/56e3cfb8/attachment.html>