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

[Jonas Ådahl]

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.

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?


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