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

[Jonas Ådahl]

On Mon, Jan 18, 2016 at 06:28:29PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 15 January 2016 at 19:30, Bill Spitzak <spitzak at gmail.com> wrote:
> > On Fri, Jan 15, 2016 at 8:08 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> >> 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 can see the reasoning behind it, at least. I'm not sure I agree, but
> those aren't the same thing.
> 
> > 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.
> 
> Yes, the triggers would involve events being sent to clients indeed.
> Codifying every exact trigger would be borderline impossible, and
> unnecessarily restrictive to compositors, so I don't think there's any
> need to do that.

If we limit lock activation to only happen as replies to events we'd
limit the compositors ability to decide when such locks should activate.
It might not always result in any input event (timeout of being within a
surface, compositor keybinding for accpeting a lock for example).

> 
> > Nor do I see any problem with race conditions provided the one-shot request
> > has an id for the triggering event:
> 
> The race here is that if you react on pointer entry, having a one-shot
> request will mean that the events you get in between entry and the
> request activating, won't be relative. I can imagine that being
> frustrating to users.
> 
> > - Client can read relative motion events (these are identical whether or not
> > pointer lock works,
> 
> ???
> 
> Relative motion does not occur without lock.

Yes they do. wp_relative_pointer is a completely separate thing. It will
emit events no matter the lock/confine situation.

> 
> Anyway, I think we all largely agree on the details, so let's look for
> the implementations (compositor and client) both, and see what
> real-world feedback falls out of those.

Yes. We should concentrate on real world applications for a while, and
luckily we can change the protocol if we see the need for it.


Jonas

> 
> Cheers,
> Daniel