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

[Peter Hutterer]

On Fri, Jan 15, 2016 at 04:08:57PM +0000, Daniel Stone 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.

tbh, I think this is just a difference in how we view the approach. I never
saw it as a "oneshot-delayed" approach, I thought of it as a "need it once"
vs "need it forever".

however, the main issue I see is that there is always a race condition. with
any delayed trigger you're guaranteed that if you request the lock, you'll
get it when appropriate. Without the immediate approach, you are racing the
user and compositor to request the lock before the trigger is undone again
(e.g.  moved out of the window). I don't know how much that will be an issue
in practice though.

Cheers,
   Peter

> 
> 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.
> 
> Cheers,
> Daniel