[PATCH weston 1/3] Introduce pointer lock interface

[Pekka Paalanen]

On Fri, 19 Sep 2014 12:46:20 -0700
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Fri, Sep 19, 2014 at 11:20 AM, 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:
> > >
> > > > Or what if an app manually starts pointer-lock because the toolkit does
> > > > not support it? This is not a use case to design for at all, but if it
> > > > happens to work, it might be a nice bonus.
> >
> > If we make it so that locking simply locks the cursor at its position,
> > it'd will just work, as the pointer cursor wouldn't move. No unexpected
> > wierd wl_pointer.motion events.
> >
> 
> I don't see any problem with locking only one of the available pointers.
> The absolute ones simply get no motion until it's unlocked.  If we add a
> set_position request to wl_relative_pointer, then I guess that would
> trigger motion on the absolute pointers.  I think it's probably fine.

Note, that it won't be motion. It'll be a leave/enter pair, because
the change in position does not come from an input device, but from
software (a client). Seems ugly to me.

> > I think that the best would be to simply not change the position or
> > state of the cursor at all. Locking would mean that while locked, the
> > wl_pointer has focus, meaning the client can change the cursor, or hide
> > it. For example if pointer-locking would be used to click-drag to select
> > items from a list (where dragging changes highlighted element), it would
> > be bad if the cursor suddenly jumps to the middle of the surface when
> > done.
> >
> > Staying where it was at the point of locking also works the same way as
> > pointer locking does in GLFW. Haven't checked SDL yet.
> >
> > What would a set_cursor_position argument do? It sounds like that could
> > be more or less used to implement actual warping by just locking, set
> > position then unlocking. It'd probably be more useful to have a
> > set_cursor_position request in wl_relative_pointer that can be used when
> > implementing pointer warping in Xwayland and then possibly even SDL and
> > GLFW. Hmm.
> >
> 
> I'm not 100% sure what you're getting at here.  However, I think we do want
> to have cases where the client is drawing a warped pointer and then the the
> pointer-lock breaks.  One example would be a VM that uses pointer_lock to
> give relative events to the client machine.  In that case, when the you
> move the pointer to the edge of the window, it sets the pointer position
> and breaks the lock.  This way it looks like the pointer is simply moving
> through the window.  RTS games will probably want to do similar things.  I
> don't think "just lock it where it is" is always going to work.

Yup, this was the reason for the set-position for cursor in
pointer-locked mode.

Without such request, the position should stay put, not warp to
middle of window or anything.


Thanks,
pq