[PATCH weston 1/3] Introduce pointer lock interface

Bill Spitzak spitzak at gmail.com
Thu Sep 25 12:32:09 PDT 2014

On 09/25/2014 06:41 AM, Matthieu Gautier wrote:

> 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 ?)

Not sure I understand. I certainly assumed the absolute and relative 
coordinates are in the same space, and find it hard to imagine any 
useful alternative.

>> Switching to relative events does not help at all, it makes clients more
>> complicated. This is because there is a race condition,
> 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.

That would work. However I think this can still be combined with my 
idea. When pointer lock is turned on, you continue getting relative and 
absolute events just like before. The only difference is you will not 
get a leave event. It also means absolute events can stop at the screen 
edge if relative ones are available.

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

That's probably what they would like, but I think it would be better to 
just add the relative info to the normal move events. The client needs 
an easy way to match up the relative and absolute events. You can't just 
switch them because the absolute events have useful information that a 
relative-event client may want (i.e. where the cursor is).

>> 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:

No, I solved that because the cursor stops being moved by the compositor 
when pointer lock is on. All the motion is due to the client setting the 
cursor position so there is no disagreement and thus no flickering.

More information about the wayland-devel mailing list