<div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote">On Sun, Sep 21, 2014 at 11:43 PM, 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 Sat, 20 Sep 2014 11:43:22 -0700 Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > On Sat, Sep 20, 2014 at 1:29 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > > > On Fri, 19 Sep 2014 20:20:53 +0200 > > 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: > > > > <div><div class="h5">> > > > > > 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. </div></div>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. </blockquote><div> </div><div>If the server sends a "leave" it becomes inert and the server assumes the client will destroy it. If the client doesn't then you leak an object but there's no real harm. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > > > 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. </blockquote><div> </div><div>fine with me </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks, pq </blockquote></div> </div></div>