[PATCH weston 1/3] Introduce pointer lock interface

[Jason Ekstrand]

On Sat, Sep 20, 2014 at 12:58 AM, Pekka Paalanen <ppaalanen at gmail.com>
wrote:

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

Ok, I think I see what you mean.  More details in the next email (trying to
slow down the thread explosion)


>
> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140920/10cacbe3/attachment.html>