Hi, This short series introduces a pointer lock interface based on the previous proposal[0] by Kristian Høgsberg from last year. The first patch adds a protocol more or less equal to Kristians proposal, but moved out of wl_seat into its own global object (currently _wl_pointer_lock), with some concerns raised in the original thread addressed. The implementation in weston is new. There was no point trying to rebase the previous implementation due to the architectural changes done since that patch was written.
The second patch introduces a client side API in toytoolkit, and the forth makes use of that API in resizor, in the same way as in the previous proposal, to resize its window. Note that the reason for having the underscore prefix is to have the possibility to push a stable variant to the wayland repo without breaking any clients implementing the experimental version. The intention is that _wl_pointer_lock ever would be considered an official interface, it would be renamed to wl_pointer_lock. In short, the interface works by having the client create a separate wl_pointer object, using wl_pointer_lock.lock_pointer, that gets focus until wl_pointer.release is requested and the surface gets deactivated. If the locked pointer object is still not released when a surface is activated again, the pointer will be implicitly locked to the special wl_pointer object again. Limitations with this approach include that it would, as far as I know, not be possible to fully implement pointer warping support in Xwayland only using this protocol. However, not sure if support for legacy concepts is within the scope of an interface like this. Maybe Xwayland needs some private way to communicate (privileged wl_xwayland interface?) for these type of things? Maybe it could be emulated by locking if warping is done with some heuristic for releasing the lock, but have not tried to implement that. We wouldn't be able to implement API of certain toolkits (for example SDL, GLFW). This I suppose is not really a big deal as it wouldn't be the first (global positions etc) and the use case is most likely to lock the pointer and get relative motion events, and there is API available in both those toolkits for that. Pointer confinement (absolute motion events, but not letting the pointer leave the surface) is another functionality that wouldn't be possible. It could be emulated by having the client lock the pointer and draw the pointer itself given the relative motion events, or simply added to this protocol in some way (wl_pointer_lock.confine_pointer?). In the previous thread, surface transformations came up as something that needed to be thought through. In the updated protocol of this series, I clarified that relative motion events are as if the surface has not been, transformed. The reasoning behind this is more or less how typical use case looks like: 1:st person 3D games. I would expect that the viewport moves the same even if the window happen to have been transformed for example zoomed or rotated. Following the trend of keeping track of these kind of stuff, I filed[1] a bug on BZ as well. Thoughts? Is this the right way to go? Jonas [0] http://lists.freedesktop.org/archives/wayland-devel/2013-February/007635.html [1] https://bugs.freedesktop.org/show_bug.cgi?id=84014 Jonas Ådahl (3): Introduce pointer lock interface clients: Introduce pointer lock API to toytoolkit resizor: Make resizor also use pointer locks for resizing Makefile.am | 11 +- clients/resizor.c | 62 +++++++++++ clients/window.c | 177 +++++++++++++++++++++++++++++ clients/window.h | 42 +++++++ desktop-shell/exposay.c | 2 +- desktop-shell/shell.c | 10 +- protocol/pointer-lock.xml | 85 ++++++++++++++ src/compositor.c | 4 + src/compositor.h | 21 +++- src/input.c | 277 +++++++++++++++++++++++++++++++++++++++++++++- 10 files changed, 678 insertions(+), 13 deletions(-) create mode 100644 protocol/pointer-lock.xml -- 1.8.5.1 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
