<div dir="ltr"><div>Hi Matthieu,<br></div>Could you please provide more explanation on what use-cases you are considering and why the current proposal fails to accomplish them?  All I was able to get from your post was the example of a TV remote.  It's all well and good to completely disagree with the proposed approach, but without a good reason as to why it doesn't work, it's kind of moot.<br><div class="gmail_extra"><br></div><div class="gmail_extra">It's also worth noting the scope of the proposal.  The primary objective here is to provide a mechanism to take a device that could be providing relative events but which the compositor has turned into a pointer and get the relative events out of it.  It's not intended to be a generic system for getting relative events.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">On that note, if you want to get a generic relative motion events, can't you just open the device and read them?  Sure we could cobble together a specification for how to read a bunch of buttons and relative events and then create a cursor from them.  I'm pretty sure it exists in the form of the USB HID spec.  How does reimplementing that in Wayland help us?  There was, at one point, a proposal for gamepads, but nothing has happened there in a while.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 9:01 AM, Matthieu Gautier <span dir="ltr"><<a href="mailto:dev@mgautier.fr" target="_blank">dev@mgautier.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I'm pretty new into wayland and the discussion is relatively long, so I may have missed arguments/constraints.<br>
However I would like to share my point of view.<br>
<br>
It seems to me that we are taking the problem the wrong way.<br>
Relative motions exist as soon as there is a device generating them. wl_pointer is just a particular interpretation of those events.<br>
<br>
In fact, we may have a system where we have relative motion events but no wl_pointer. Think about a smart tv with a remote control with accelerator/gyroscope detectors.<br>
This remote may behave as a mouse, generating relative motion events. But the main interface of the TV may have no pointer. The interface should been a set of icons and user move between them with the remote buttons.<br></blockquote><div><br></div><div>If you're just pressing buttons to move between icons, then "pointer" is probably the wrong way to look at it anyway.  It's more "arrow keys" than a pointer.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the same way, we may want that special applications still have access to motion events:<br>
- A web browser that will display itself the pointer (or activate wl_pointer in the compositor)<br>
- A video game<br>
- Any application that want make gesture recognition.<br>
<br>
In this context, wl_pointer is a special use-case of a shell and having a mouse device doesn't imply having a pointer.<br>
<br>
Relative motions should be always available (if there is a device) and wl_pointer should be created on top of relative motions.<br>
Trying to reduce the wl_pointer behavior to have the raw events seems to me the contrary of what we have to do.<br>
<br>
<br>
What I propose is :<br>
<br>
- Having a way to get "relative input object" (lets call it wl_relative for now) from wl_seat.<br>
- Having a way to get a wl_pointer from the wl_seat at it is already the case.<br>
<br>
Relative events a sent to client if it is active (It is to the compositor to decide this, as usual) whatever there is a wl_pointer or not.<br>
<br>
The pointer lock interface will become some kind of "deactivate/configure wl_pointer".<br>
<br>
# Functionally :<br>
<br>
A combination of :<br>
- Hide the cursor (already available with wl_pointer.set_cursor)<br>
- Don't not update wl_pointer position from relative events.<br>
- Confine the pointer position into my wl_surface.<br>
- Set wl_pointer at this position.<br>
<br>
- A fps game will hide the cursor and deactivate update of wl_pointer position.<br>
- A strategy game will just confine the pointer.<br>
- A application with a 3D view that what to rotate it when user drag the mouse will just deactivate update of pointer position between button_down and button_up.<br>
- A application that just want relative motion events do nothing.<br>
<br>
At any time, relative motion events are sent to client through the wl_relative object. Regardless of the state of wl_pointer.<br>
It is up to the client to handle events from wl_pointer or wl_relative depending of which kind of information it wants.<br>
<br>
<br>
# Interface :<br>
<br>
The wl_pointer could gain two (four?) more requests :<br>
<br>
- set_mode(mode, callback)<br>
- reset_mode()<br>
( - has_mode<br>
- get_mode )<br>
<br>
The default mode is the mode we have for now (no special constraints)<br>
A client can change the mode of a wl_pointer. It gets a callback.<br>
When compositor stops the special mode (or refuse it) the done event of the callback is sent.<br>
When the client has finished with special mode, it sends the reset_mode request.<br>
<br>
The wl_pointer.leave event may or not be sent to client when the done event is sent (The pointer may still being inside the wl_surface when special mode ends)<br>
However a wl_pointer.leave event implies a done event. (We cannot have a special mode if we don't have the pointer focus)<br>
<br>
<br>
On the interface to get the wl_relative object from seat, it depends :<br>
<br>
Is there a possibility to have several cursor on one seat ?</blockquote><div><br></div><div>One cursor per seat.  If there are multiple physical mice, then you get an aggregate of all the mice.  You can, however, have multiple seats in which case you will get multiple pointers.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (Two mouses moving two cursors)<br>
Does wl_seat.get_cursor return always a proxy to the same object ?<br></blockquote><div><br></div><div>Yes, all pointers created from the same seat are identical.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- If there is only one cursor, we can simply add a get_relative request to wl_seat.<br>
- If not, we should get a object from the other.<br>
  . Ideally, get the wl_pointer from wl_relative. (and wl_relative from wl_seat)<br>
  . Practically, cause of the existent, get wl_relative from wl_pointer.<br>
<br>
<br>
Regards,<br>
Matthieu Gautier.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div>