[PATCH weston 1/3] Introduce pointer lock interface

[Matthieu Gautier]

Hello,

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 
accelerator/gyroscope detectors.
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.
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 
case.

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 
"deactivate/configure wl_pointer".

# 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 
position.
- 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)
- reset_mode()
( - 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 
request.

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 
to wl_seat.
- If not, we should get a object from the other.
   . Ideally, get the wl_pointer from wl_relative. (and wl_relative from 
wl_seat)
   . Practically, cause of the existent, get wl_relative from wl_pointer.


Regards,
Matthieu Gautier.