<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Sat, Sep 20, 2014 at 12:58 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 19 Sep 2014 12:46:20 -0700 Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > On Fri, Sep 19, 2014 at 11:20 AM, Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> 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 <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> > > 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. </blockquote><div> </div><div>Ok, I think I see what you mean. More details in the next email (trying to slow down the thread explosion) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > > 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 </blockquote></div> </div></div>