[PATCH v3 weston] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On Thu, Jun 25, 2015 at 9:38 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

> This version adds support for changing the lock/confine region after the
> lock was created.
>
> For pending wl_confined_pointer lock, the effect is the same as for
> wl_locked_pointer. But for an already activated confinement, it affects the
> pointer, i.e. warps the pointer to somewhere within the region.
>

You do realize you have provided exactly what I have been requesting. The
client can now move the cursor arbitrarily around by sending 1x1
confinement regions. IMHO it would make more sense to fix the "hint" call
to do the same thing so you reduce the size of the code.

I am primarily concerned with reusing this api for "slow sliders", and for
more complex transformation of 2d movement to screen position, such as
locking the cursor to the surface of a rendered trackball. I believe it can
be done with the following changes:

- Replace set_cursor_position_hint with set_cursor_position. The result is
identical to setting the confine region to a very tiny one such that the
cursor cannot move. Note that this will not break anything: your current
api requires the client to hide the cursor, so the fact that this actually
moves it will not be visible!!!

- Add a third method to _wl_pointer_lock of making a lock that expires when
the mouse button is released (it is destroyed by exactly the same rules as
the automatic grab is expired). It takes an event identifier to indicate
which mouse button press it is for. Creation of this immediately activates
it (I'm not sure if the activation event should be sent or implied), then
deactivates it when the button is no longer pushed.

You should also merge the _wl_locked_pointer and _wl_confined_pointer
objects since they are nearly identical. The result has both
"set_cursor_position" and "set_region" methods. set_cursor_position is
exactly the same as setting a very tiny region (in case you are wondering
what it should do before "activation").

A fourth type of lock may be useful, too, though I am not very sure how it
should work. This is to allow the client to position the cursor in sync
with it's drawing even when the mouse is not held down. The difference is
that this lock is lost on an exit event, and something is done so that a
client continuously warping the cursor to the middle of the surface cannot
prevent these exit events. The idea is that this is somewhat less dangerous
than your original locking and thus the compositor is more likely to grant
it. This locking is useful for highlighting fine detail to show what will
be selected on click.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150626/b8cb616e/attachment-0001.html>