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

[Bill Spitzak]

On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
>
> On 12 January 2016 at 22:28, Bill Spitzak <spitzak at gmail.com> wrote:
> > 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.
>
> For what it's worth - post-hoc expansion on my reasoning - I think
> Bill has the genesis of a point here. Usually, our requests have
> followed one of two patterns: either you request activation in
> response to a specific event (button or key event allows you to create
> a selection), or retained state (creating a wl_data_device gets you
> selection/etc events on that seat until you destroy it).
>
> The proposed one-shot-but-delayed request to me felt like a really
> awkward compromise between the two, and not really one backed up by a
> strong enough usecase to justify a third (delayed but not retained)
> model for requests taking effect.
>
> It's entirely possible that there's something I'm missing here, but
> for consistency if nothing else, having the split instead be between
> these two classic methods (oneshot-immediate vs. fully-retained,
> rather than oneshot-delayed vs. fully-retained) could be good for
> future versions.
>

I would agree there is something missing here.

I do not see any reason for anything other than a "one shot" which is
created by the client *AFTER* it receives the possibly-triggering input
event. I am still waiting for a description of how one of these pre-set
locks is triggered, I have serious doubts that any possible trigger could
be something other than an action that would send an event to the client,
or at a moment the client is doing something like configuring the surface.

Nor do I see any problem with race conditions provided the one-shot request
has an id for the triggering event:

- Client gets event that it thinks should trigger pointer-lock/confine

- Client sends pointer-lock/confine request which includes the event serial
number (and creates the pointer-lock proxy object)

- Client can read relative motion events (these are identical whether or
not pointer lock works, and also correct for motion before the pointer lock
request was received by the compositor). Client can also read absolute
pointer motion events, but it needs to know these change depending on
whether they are before or after the accept event.

- Client can change the confinement region (ie it can move the cursor).
These are ignored if pointer lock has been rejected or has expired

- Client (may) get an accepted event stating that pointer lock worked.

- Client gets a cancelled event. If it did not get an accepted event then
it knows pointer lock did not work.

Imagine the compositor cancels pointer-lock on the next mouse-up event, and
a client tries to grab pointer-lock on mouse down. Normal event sequence
(--> indicates requests)

  button-down event
  --> pointer lock request
  --> set cursor image
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  accepted event
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  button-up event
  cancelled event
  motion/enter/exit events due to grab being lost
  --> set cursor image

Now imagine the simplest race, where the compositor sees the mouse button
being released before it gets the pointer-lock request:

  button-down event
  --> pointer lock request
  --> set cursor image
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  motion event
  --> cursor motion
  button-up event
  motion/enter/exit events due to grab being lost
  cancelled event (due to compositor finally seeing the pointer lock
request)
  --> set cursor image

Client can tell this happened because it did not get an accepted event. But
it is also interesting that a client may not care: it should act exactly
the same and to the user it looks like the pointer-lock gesture worked,
except the end position of the cursor is different.

I can imagine schemes where the end cursor position is correct, but I think
it requires putting an event serial number on the cursor motion requests.
The idea is that if the mouse button has not been pressed again, it is
warped back to the set position plus the result of any later motion events.
Compositor sends accepted+cancelled to indicate this happened. Not sure if
it is worth the complexity however.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20160115/e98f50db/attachment-0001.html>