<div dir="ltr">On Fri, Sep 19, 2014 at 2:54 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 19 Sep 2014 08:33:13 +0200<br>
<div><div class="h5">Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
<br>
> On Thu, Sep 18, 2014 at 10:43:47AM -0700, Jason Ekstrand wrote:<br>
> > On Thu, Sep 18, 2014 at 2:26 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br>
> ><br>
> > > On Wed, 17 Sep 2014 22:35:40 +0200<br>
> > > Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br>
> > ><br>
> > > > On Wed, Sep 17, 2014 at 11:16:06PM +0300, Giulio Camuffo wrote:<br>
> > > > > 2014-09-17 23:11 GMT+03:00 Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>>:<br>
> > > > > > On Wed, Sep 17, 2014 at 10:56:13PM +0300, Giulio Camuffo wrote:<br>
> > > > > >> I haven't looked at the implementation yet, just at the protocol,<br>
> > > but<br>
> > > > > >> isn't _wl_pointer_lock.lock_pointer() returning a new wl_pointer a<br>
> > > > > >> problem? Objects should have a unique factory interface, or else the<br>
> > > > > >> version of the interface can't be determined.<br>
> > > > > ><br>
> > > > > > Is it really? In the implementation below, the wl_pointer object gets<br>
> > > > > > the same version as the wl_pointer object that is locked. It is also<br>
> > > > > > specified in the last paragraph of _wl_pointer_lock.lock_pointer.<br>
> > > > ><br>
> > > > > Mmh, then maybe it is fine. I'm not convinced actually, but I'm too<br>
> > > > > tired now. :)<br>
> > ><br>
> > > No, it's not fine. You cannot define exceptions to the versioning rules<br>
> > > in a protocol spec. We have common code in libwayland handling all<br>
> > > runtime versioning, and you just cannot implement any exceptions.<br>
> > ><br>
> ><br>
> > Technically, those haven't been merged yet... So, technically, we could<br>
> > have it inherit the version from the wl_pointer.  That said, I think we'll<br>
> > regret if we do.  Even if we did do that, it would cause problems, not<br>
> > because we couldn't update wl_pointer, but because we really couldn't<br>
> > update wl_pointer_lock.  All in all, it's a bad plan.<br>
> ><br>
><br>
> So, from what I've heard here now is it's clear we don't want to create<br>
> a new wl_pointer object. Other than the versioning issue, we'd have<br>
<br>
</div></div>You could create a wl_pointer, if you do it from interface whose<br>
ancestor is wl_seat, or directly a request in wl_seat. But it does have<br>
downsides like not being able to let the extension mature in Weston<br>
before moving it to Wayland core.<br>
<span class=""><br>
> non-sensible requests (set_cursor) on the additional wl_pointer, and<br>
> potentially more as wl_pointer is extended. The alternatives that has<br>
> come up in IRC discussions and backlog reading are:<br>
><br>
>  1) Create a wl_relative_pointer that would replace wl_pointer, i.e.<br>
>     have its own button, axis, etc events. This would solve all problems<br>
>     related to versioning and wl_pointer being extended, but brings a<br>
>     bunch of other problems for example we'd have to extend<br>
>     wl_relative_pointer each time wl_pointer is extended to keep up, as<br>
>     well as the issue where a wl_pointer is used in a interface or<br>
>     request.<br>
<br>
</span>Either you use wl_pointer and get extensions automatically even if you<br>
don't want to, or you use a new interface that you have to extend<br>
explicitly if you want the same as in wl_pointer. Two sides of a coin.<br>
<br>
As concluded in IRC, wl_pointer is not used as argument in any messages.<br>
<span class=""><br>
>  2) Add "begin" and "end" events to wl_pointer_lock that changes the<br>
>     state of an existing wl_pointer. After a wl_pointer_lock.begin is<br>
>     sent, wl_pointer.motion sends relative motion events. After<br>
>     wl_pointer_lock.end it'd revert back to sending absolute motion<br>
>     events.<br>
<br>
</span>This might be confusing if a client creates several wl_pointer objects<br>
for the same seat underlying a wl_seat.<br>
<br>
Apart from being confusing just by changing the meaning of an event<br>
via a mode.<br>
<span class=""><br>
>  3) Extend wl_pointer similar to how wl_viewport extends wl_surface with<br>
>     a wl_relative_pointer (different from in (1)). Such a<br>
>     wl_relative_pointer would, to begin with, only have one request<br>
>     (release) and one event (motion). It wouldn't change anything to the<br>
>     wl_pointer object, it'd still receive button, axis etc events, but<br>
>     motion events are turned into relative motion events via<br>
>     wl_relative_pointer, not affecting the position of the cursor, i.e.<br>
>     not resulting in wl_pointer.motion events.<br>
<br>
</span>This is an interesting idea. I wonder how it works if the client has<br>
two parts (say, libraries or toolkits with their own input processing),<br>
therefore has multiple wl_pointer objects for the same thing, and only<br>
few of them have the pointer_lock interface associated.<br>
<br>
Or what if an app manually starts pointer-lock because the toolkit does<br>
not support it? This is not a use case to design for at all, but if it<br>
happens to work, it might be a nice bonus.<br>
<span class=""><br>
> To me, alternative (3) seems like the best choice. It'd give us<br>
> possibility to continue to control the pointer cursor via the original<br>
> wl_pointer object, as it will still have focus. It also allows us to make<br>
<br>
</span>I don't think we ever want the compositor drawing the cursor in<br>
pointer-locked mode... do we? Would there be any use cases benefitting<br>
from it?<br></blockquote><div><br></div><div>There's an additional problem here: where should the cursor be drawn? Will wl_relative_pointer have a set_cursor_position argument while in relative mode?<br><br></div><div>I could see arguments in favor of it (ability to reuse the cursor plane), but we can leave this out for now. If we want to add it back, we say that the cursor is always drawn in the center of the surface, unchanging, and if apps want to remove it, they blank it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Though, I don't see anything wrong with requiring the client to<br>
explicitly unset the cursor when pointer-lock activates. Or are there<br>
any room for races where the cursor might flicker?<br>
<span class=""><br>
> use of any future wl_pointer additions (problem being that they could<br>
> potentially conflict, but that wouldn't be unique for<br>
> wl_relative_pointer AFAIK). Alternative (2) would give us the same<br>
> benefits, but it feels rather awkward to temporarily change the meaning<br>
> of wl_pointer.motion.<br>
<br>
</span>Agreed about 2).<br>
<span class=""><br>
> Given that the three above choices are more or less semantically<br>
> equivalent it makes sense to try it out in a already used API. From what<br>
> I can see, the two common places it'd be used are SDL and GLFW, which<br>
> have different API's doing more or less the same thing, so it'd probably<br>
> be good to try it out in both of these.<br>
<br>
</span>A very good idea. That is how we get some perspective to the design and<br>
find issues.<br>
<br>
There are at least to different basic use cases:<br>
- Quake, i.e. FPS-games with mouse-look<br>
- a strategy game, which still uses a cursor, but implements special<br>
  behaviour when running against window edges like scrolling the view,<br>
  likely with the pointer confined to the window<br></blockquote><div><br>A third use case. A less exciting one, but still an important one: 
implement the W3C pointer-lock extension on top of the Wayland API.<br>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A good question is, do we want to support the latter with<br>
pointer-lock, or should it be another extension?</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, the latter probably wants the same motion acceleration algorithm<br>
as the desktop has, but the former probably not.<br><div class=""><div class="h5"></div></div></blockquote><div><br></div><div>This is effectively an X server grab with "confine_to". I'd take a look at some existing RTS games (FreeCiv? OpenTTD?) and see how they implement that mode.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
Thanks,<br>
pq<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>