On Sat, Sep 20, 2014 at 12:58 AM, Pekka Paalanen <[email protected]> wrote:
> On Fri, 19 Sep 2014 12:46:20 -0700 > Jason Ekstrand <[email protected]> wrote: > > > On Fri, Sep 19, 2014 at 11:20 AM, Jonas Ådahl <[email protected]> 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 <[email protected] > > > > > 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 >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
