[PATCH weston 00/17] Relative pointer motions, locking and confinement
Steven Newbury
steve at snewbury.org.uk
Tue Dec 2 06:44:55 PST 2014
On Tue, 2014-12-02 at 21:49 +0800, Jonas Ådahl 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
I get "You do no have access to this repository." from the bitbucket
repo.
> 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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141202/051341ef/attachment.sig>
More information about the wayland-devel
mailing list