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

[Daniel Stone]

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.

> 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.

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.

Cheers,
Daniel