[PATCH weston 1/3] Introduce pointer lock interface
dev at mgautier.fr
Tue Sep 23 09:01:48 PDT 2014
I'm pretty new into wayland and the discussion is relatively long, so I
may have missed arguments/constraints.
However I would like to share my point of view.
It seems to me that we are taking the problem the wrong way.
Relative motions exist as soon as there is a device generating them.
wl_pointer is just a particular interpretation of those events.
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
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
In the same way, we may want that special applications still have access
to motion events:
- A web browser that will display itself the pointer (or activate
wl_pointer in the compositor)
- A video game
- Any application that want make gesture recognition.
In this context, wl_pointer is a special use-case of a shell and having
a mouse device doesn't imply having a pointer.
Relative motions should be always available (if there is a device) and
wl_pointer should be created on top of relative motions.
Trying to reduce the wl_pointer behavior to have the raw events seems to
me the contrary of what we have to do.
What I propose is :
- Having a way to get "relative input object" (lets call it wl_relative
for now) from wl_seat.
- Having a way to get a wl_pointer from the wl_seat at it is already the
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.
The pointer lock interface will become some kind of
# Functionally :
A combination of :
- Hide the cursor (already available with wl_pointer.set_cursor)
- Don't not update wl_pointer position from relative events.
- Confine the pointer position into my wl_surface.
- Set wl_pointer at this position.
- A fps game will hide the cursor and deactivate update of wl_pointer
- A strategy game will just confine the pointer.
- 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.
- A application that just want relative motion events do nothing.
At any time, relative motion events are sent to client through the
wl_relative object. Regardless of the state of wl_pointer.
It is up to the client to handle events from wl_pointer or wl_relative
depending of which kind of information it wants.
# Interface :
The wl_pointer could gain two (four?) more requests :
- set_mode(mode, callback)
( - has_mode
- get_mode )
The default mode is the mode we have for now (no special constraints)
A client can change the mode of a wl_pointer. It gets a callback.
When compositor stops the special mode (or refuse it) the done event of
the callback is sent.
When the client has finished with special mode, it sends the reset_mode
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)
However a wl_pointer.leave event implies a done event. (We cannot have a
special mode if we don't have the pointer focus)
On the interface to get the wl_relative object from seat, it depends :
Is there a possibility to have several cursor on one seat ? (Two mouses
moving two cursors)
Does wl_seat.get_cursor return always a proxy to the same object ?
- If there is only one cursor, we can simply add a get_relative request
- If not, we should get a object from the other.
. Ideally, get the wl_pointer from wl_relative. (and wl_relative from
. Practically, cause of the existent, get wl_relative from wl_pointer.
More information about the wayland-devel