On Wed, Sep 17, 2014 at 09:55:36PM +0200, Axel Davy wrote: > On 17/09/2014 21:39, Jonas Ådahl wrote : > >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 > > > Thanks for getting into this. > > Could you clarify where the cursor should be during the lock, > and what should be the cursor position when a lock is ended ?
Sure. Can add a clause saying that the the position of the actual pointer will stay where it was before the lock was initiated (be it by lock_pointer or surface activation). Regarding the cursor, hiding it during it being locked probably makes most sense. Jonas > > Axel Davy _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
