<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Jason,<br>
<br>
Well, I'll try to be more concise.<br>
<br>
In fact, there are two unrelated parts in my proposition :<br>
<br>
# First part : getting relative events<br>
<br>
Passing through a wl_pointer that may not exists to get relative
events seems a bit odd to me.<br>
<br>
My main idea is to have a new object (I've call wl_relative) *not
related* to wl_pointer that send to client the relative events.<br>
If a client want relative events, it open this object and receive
events from it. Simply.<br>
No need to look the wl_pointer or anything else.<br>
<br>
The wl_pointer still continue to work as usual. There is strictly
no change in that part.<br>
<br>
The only relation we may find between wl_relative and wl_pointer
is that relative events are sent only when the wl_surface as the
focus.<br>
In a first approximation, we can say that the wl_relative focus is
the same of wl_pointer focus and that relative events are send
only when wl_pointer.motion are send (ie, between wl_pointer.enter
and wl_pointer.leave)<br>
But a special compositor could follow its own rules.<br>
<br>
# Second part : pointer lock<br>
<br>
The pointer lock should not be related to relative events. This is
two different parts.<br>
<br>
To acquire a pointer lock, a client just ask it.<br>
It can be by the request wl_pointer.get_lock(lock_type) (I've
called it set_mode in my past mail but get_lock is a better name)<br>
<br>
This request return a wl_callback used by the compositor to end
the lock (either cause it refuse it or the lock normally ends)<br>
The lock can be released by the client using
wl_pointer.release_lock() (former reset_mode)<br>
<br>
The lock_type can be :<br>
- lock : Do not move the pointer (What was in the Jonas' proposal)<br>
- confine : Confine the pointer into the surface.<br>
<br>
During a lock, all events are still send as usual :<br>
- Relative events from wl_relative are not impacted by the
wl_pointer lock<br>
- wl_pointer.motion are still send in confine mode<br>
- wl_pointer button, axis events are still sent<br>
<br>
# Remarks and QA:<br>
<br>
The main difference compared to Jonas' proposal is that I totally
separate the relative events problem from the pointer lock
problem. (I maybe should have start by this :) )<br>
In Jonas' proposal you have to acquire the pointer lock to get
relative events. In my proposition we can get one without having
the other.<br>
<br>
I don't especially care if this is my proposal or Jonas' ones that
is kept. But separate the two part in unrelated problems seems
better to me.<br>
<br>
I've you give me times, I will send you a patch of wayland.xml to
describe more precisely what I'm thinking about.<br>
It could be interesting that Jonas update its protocol xml with
remarks from others to be sure that we compare up to date proposal
and not miss anything.<br>
<br>
- Why not let the application open the device ? <br>
=> For security reasons. We probably don't want that any
applications can open input devices and read from them all events.<br>
=> Scalability. Devices are not always mouses. Applications
may not know how to read them.<br>
In my past job, I've made a android
application that connect to the STB in Wifi and discuss directly
with the compositor to send input events. There was no device to
read from except a socket.<br>
- What my proposal can do that Jonas' one can't do ?<br>
=> The only thing I can find is the case where a seat doesn't
have a wl_pointer but have relative events. For all the rest,
Jonas' proposal seems to work.<br>
=> My proposition seems simpler to me. Less dependencies
between elements, less questions about who create and release
objects. (But It's maybe also cause it's mine :) )<br>
<br>
Regards,<br>
Matthieu.<br>
<br>
Le 23/09/2014 23:42, Jason Ekstrand a écrit :<br>
</div>
<blockquote
cite="mid:CAOFGe94xjGqE6YuPC7_671CFGBkciVrTKeX3ZNr3o8ptyD4Www@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true" 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>
</div>
</blockquote>
Exactly, there is no pointer in this example. But there are relative
events applications may want to have.<br>
<blockquote
cite="mid:CAOFGe94xjGqE6YuPC7_671CFGBkciVrTKeX3ZNr3o8ptyD4Www@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
_______________________________________________<br>
wayland-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:wayland-devel@lists.freedesktop.org"
target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a moz-do-not-send="true"
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>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
wayland-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>