[PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On Mon, Jan 11, 2016 at 11:03 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

>
> Come to think of it, we would still introduce a race condition, just for
> the other use case. If the intention is that the lock should be
> one-shot, the client may not be able to respond with a .destroy() in
> time, resulting in the compositor potentially re-locking when that is
> not what the client intended. To support both use cases race free we'd
> need to bake that into the request creating the lock. Is it worth
> complicating the request for fixing both races?
>

There should *only* be "one shot" requests, which are very quickly accepted
or denied by the compositor. The client creates it in response to an input
event, and it includes the input event id.

Most/all things that triggers pointer lock (the mouse entering the region,
the mouse being pressed in the region, a press+release in the region, a
keystroke) could be implemented by clients and it does not do any pointer
lock protocol until after it has detected the triggering event, and thus
can include the event id.

It is extremely unclear from your proposal whether you are going to allow a
pointer lock to happen without an input event to the client. Some
description of how pointer lock looks to a user would help here. Some
guesses of mine:

- Pointer lock is "grabbed" immediately on program startup, or when the
surface is full-screened. I think this could be done by the client making
the request at these points with a zero event id. Also responding to
mouse-enter events would probably cover all the real-world examples.

- Some kind of global compositor-chosen hot key triggers pointer lock. But
then it is rather mysterious how you deal with pointer lock requests from
more than one client at the same time. If that is chosen by the keyboard
focus, then the client will get the keystroke and thus the client can
trigger pointer lock in response to the keystroke.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20160112/744c022f/attachment.html>