[PATCH weston 1/3] Introduce pointer lock interface

[Matthieu Gautier]

Le 24/09/2014 21:44, Bill Spitzak a écrit :
> On 09/24/2014 09:04 AM, Matthieu Gautier wrote:
>
>> If for any reason the user move the mouse and the pointer position
>> doesn't change (cause of pointer lock or pointer is already on a screen
>> corner),
>> a motion event is still generated but with surface_x/surface_y being the
>> same as the previous ones.
>
> This is exactly (except for the pointer-lock) what I would suggest. Some
> X servers (IRIX I think) did exactly this when the mouse hit the edge of
> the screen, and it was very useful for making huge menus scroll as the
> user dragged the mouse. Later X servers did not do this and it made some
> nice menu interaction impossible (we had to resort to the
> warp-the-cursor hack you mention games doing).
>
> These old systems did use low-resolution mice, so it knew a motion event
> corresponded to one pixel. This may be a problem with modern systems as
> the events are delivered for very tiny movements. An alternative idea is
> to deliver motion events as though the xy position kept moving outside
> the screen, but if the user moves the mouse back toward the screen such
> that the cursor should move away from the edge, the xy position jumps
> back inside the screen.
>
> Pointer lock:
>
> I'm not sure what "wl_pointer" is, but there have been a lot of strange
> statements that seem to indicate people think it is impossible for the
> motion events to have something other than where the user sees the
> cursor. There are in fact two objects of interest:
>
> 1. A cursor. This is an image (usually an arrow) that is composited into
> the display. There is one cursor per seat. This can be placed anywhere
> on the screen. Usually the compositor does this, but when pointer-lock
> is on the client does it.
>
> 2. An xy position. This is a per-seat xy position. Motion events and
> enter/leave are delivered by this. The compositor updates it based on
> input devices attached to the seat. It might also move it when pointer
> lock is canceled.
>
> These are DIFFERENT!!! It should be obvious that if the client can move
> the cursor there is a race condition if the motion events depend on that
> position. Therefore they must be independent.

My separation was more between relative events and their integration to 
get absolute position.

But yes, there are two different parts and they should not been combine.

>
> The client should be allowed to move the cursor anywhere while pointer
> lock is on (the compositor may clamp it to be on-screen). It has ZERO
> effect on motion events it gets.
>
> PS: The client cannot make a "fake cursor", as several have suggested,
> because when pointer lock is released the xy position and cursor had
> better be in the same location the user thought it was. Therefore the
> compositor has to know where the cursor is.
>
> Relative events:
>
> You should not have relative events.
>
> As long as moving the mouse actually produces different numbers (ie it
> does not stop at any edges) then it is trivial for the client to extract
> relative events, by subtracting the previous position.


How do you handle transformed surfaces ?

If a surface is scale by 0.5 for example. Absolute cursor seems to move 
twice its speed from client pov.

Do we want game to turn player position quickly in this situation ? (And 
with rotation transformation ?)

>
> Switching to relative events does not help at all, it makes clients more
> complicated. This is because there is a race condition, the compositor
> may have delivered some normal motion events before responding to the
> pointer lock. The client has to deal with these so it must already have
> code to deal with absolute events and therefore relative events do not
> save anything.

This is why I was thinking of a way to send relative events 
(untransformed events is better name) always (as far as the client want it)

If there is no relation between pointer lock and untransformed event, 
there is no race condition.

Client "open untransform event object" and deal with untranformed events 
without care of absolute move events from the pointer.

>
> If the input device is relative (ie a mouse), pointer lock should allow
> the xy position to move anywhere, not limited to the screen. This is the
> only change needed to get the benefits of "relative events".
>
> Confine:
>
> "confine to surface" is useless. This is because the client will always
> want to confine to a widget, which the compositor is unaware of.
>
> All that is needed is for the client to be able to move the cursor while
> pointer lock is on. It can then implement any confinement rules it
> wants, such as mapping to a spherical projection.
>
> So please don't have a "confine" mode.

I disagree here.

Compositor has to know what is the confine zone.
If we rely on the client to replace the cursor position we may face off 
some kind of flickering cursor position:

- Compositor will displayed the cursor at its new position.
- It send the cursor position to the client
- Client change the position of cursor cause of personal rule about 
confine zone.
- If the user continue to move mouse, he will see cursor move and be 
reset at same position all the time.

To handle the case of the client wanting to confine the cursor to a 
widget, we may set a confine region.


>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel