[PATCH weston 1/3] Introduce pointer lock interface

[Matthieu Gautier]

Le 25/09/2014 21:32, Bill Spitzak a écrit :
> 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.

Client can't know what is the transformation matrix applied to the 
surface. So it can't calculate the raw event from the absolute position 
of the pointer.

So we need to send relative/raw/untransformed events on top of absolute 
position. We cannot just keeping send absolute events and lets the 
client decide.

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

As Jasper said, it will be a waste of bandwidth as, most of the time, 
clients don't want relative events. We have to send relative events only 
if client asks it.

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

Agree with that. I've forget about the lock.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel