[PATCH weston 1/3] Introduce pointer lock interface

[Pekka Paalanen]

On Sat, 20 Sep 2014 11:43:22 -0700
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Sat, Sep 20, 2014 at 1:29 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Fri, 19 Sep 2014 20:20:53 +0200
> > Jonas Ådahl <jadahl at gmail.com> wrote:
> >
> > > On Fri, Sep 19, 2014 at 11:00:21AM -0600, Jasper St. Pierre wrote:
> > > > On Fri, Sep 19, 2014 at 2:54 AM, Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> > > >

> > > > > > non-sensible requests (set_cursor) on the additional wl_pointer,
> > and
> > > > > > potentially more as wl_pointer is extended. The alternatives that
> > has
> > > > > > come up in IRC discussions and backlog reading are:
> > > > > >
> > > > > >  1) Create a wl_relative_pointer that would replace wl_pointer,
> > i.e.
> > > > > >     have its own button, axis, etc events. This would solve all
> > problems
> > > > > >     related to versioning and wl_pointer being extended, but
> > brings a
> > > > > >     bunch of other problems for example we'd have to extend
> > > > > >     wl_relative_pointer each time wl_pointer is extended to keep
> > up, as
> > > > > >     well as the issue where a wl_pointer is used in a interface or
> > > > > >     request.
> > > > >
> > > > > Either you use wl_pointer and get extensions automatically even if
> > you
> > > > > don't want to, or you use a new interface that you have to extend
> > > > > explicitly if you want the same as in wl_pointer. Two sides of a
> > coin.
> > > > >
> > > > > As concluded in IRC, wl_pointer is not used as argument in any
> > messages.
> > >
> > > But it is by wl_pointer_lock.lock_pointer, and who says it'll be the only
> > > place its used as an argument?
> >
> > I think wl_seat might be a better argument. After all, all
> > wl_pointer objects created from the same wl_seat in the same way
> > will be identical. I think we should keep it that way, too.
> >
> 
> That's a decent idea.  We could simply have
> wl_pointer_lock.get_relative_pointer(seat) which creates a relative
> pointer.  At that point, all the absolute pointers get a leave.  The
> client, if it wants, can create multiple relative pointers.  Once all of
> them are destroyed, the absolute pointers get an enter again, and off we go.

Mind, you are saying that simply a client creating the
wl_relative_pointer will never get normal wl_pointer events as long as
a wl_relative_pointer object exists. Is this a deliberate design
choice? You seem to contradict it right below here with the leave
events.

> One note though:  I don't think we want to try too hard to make multiple
> pointers per seat seamless.  That's going to be an awkward case no matter
> what we do.  We do need to make it well-defined.  I think that having all
> the absolute pointers get a leave is a reasonable way to do that.  If the
> compositor has to break the lock, all the relative pointers should get a
> leave and absolute motion resumes.  (It probably won't get an absolute
> enter right away.  The use probably went to an expose or alt-tab view so it
> probably would have gotten an absolute leave anyway.)

Yes, that is a logical consequence of the "all <wl_* input device type>
objects for the same wl_seat and created the same way are
identical." :-)

It's actually a pretty logical implication from the globals: binding
several times to a specific global name creates identical objects that
all refer to the same thing, and act the same way at the same time.

This might be a good design rule to set, don't you think?

> > > Hmm. Maybe we need to lock pointer given a seat instead. It'd change the
> > > "mode" of the underlying pointer to be locked in its position, i.e. not
> > > send any wl_pointer.motion events. Locking could then be ref counted, so
> > > that as long as more than one wl_relative_pointer is alive, it's in
> > > relative mode. Maybe thats unnecessarily complex though.
> >
> > We are distinguishing "wl_relative_pointer exists" from
> > "pointer-lock is active", right?
> >
> > A question is: how does the client know when pointer-lock is
> > active? I think we'd need something like
> > wl_relative_pointer.enter/leave.
> >
> 
> I'm still a fan of destroying relative pointers when not in use.  It's a
> bit more protocol churn, but it makes it clear when they are/are not
> active.  Maybe enter/leave will work, but I'm not convinced it's the right
> way forward.  I'll have to give that a bit more thought before I could give
> a real solid argument though.

Yes, of course. It's more a matter of how does the client know to
destroy the wl_relative_pointer, when the compositor chooses to
deactivate the pointer-lock. If there is a leave event for that, good.

I think with this, it could actually make sense what you said above: no
normal wl_pointer events as long as any wl_relative_pointer exists.
This would strongly push app devs to destroy the wl_relative_pointer at
the right time, I believe.

And then we need a backup plan for clients that do not destroy it, for
protocol definition completeness.

> > > I can imagine that the second use case may very well be implemented both
> > > with confinement and relative pointer events and as such relative
> > > pointer events would need support both non-accelerated and accelerated
> > > modes.
> >
> > IMHO that raises the question: should be have separate interfaces,
> > or at least separate requests for asking raw relative motion vs.
> > desktop-like relative (i.e. accelerated) motion?
> >
> > Or should wl_relative_pointer maybe deliver both at the same time?
> >
> > Maybe have separate requests for creating the wl_relative_pointer...
> >
> 
> Both of those seem reasonable to me.

I would suggest we go with a separate request with "raw" input data.
This way we can easily add it later. I suspect it may also need
libinput additions. We don't even have a good definition of "raw" yet,
either, AFAIK. Going with just the normal (accelerated) motion for now
should be easier to try out.


Thanks,
pq