[PATCH weston 00/17] Relative pointer motions, locking and confinement
Jonas Ådahl
jadahl at gmail.com
Tue Dec 2 06:47:01 PST 2014
On Tue, Dec 02, 2014 at 02:44:55PM +0000, Steven Newbury wrote:
>
> 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.
Should be fixed now. Thanks for reporting.
Jonas
>
> > 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
> >
> >
More information about the wayland-devel
mailing list