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 > > > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
