[PATCH weston v3 3/3] Introduce wl_relative_pointer interface

[Bill Spitzak]

On 10/08/2015 10:15 AM, Derek Foreman wrote:
> On 07/10/15 07:41 PM, Jonas Ådahl wrote:

>>> I think it would be nice to land this in the same release cycle (ie:
>>> this one) as pointer confinement, because I think the two features
>>> really go hand in hand.
>>
>> Indeed. Relative pointer events are quite useless if you loose focus
>> almost immediately

Wrong. Relative pointer events are useful if the client has a grab, such 
as when the user is holding the mouse button down. They thus don't loose 
focus "almost immediately", they lose it when the user releases the 
mouse button.

For instance they could be used to scroll a very tall popup menu as the 
mouse hits the edge of the screen. Or to make a smooth drawing stroke 
even if the path the user makes goes outside the screen.

If the client could also control where the cursor is drawn then this 
would work even for clients that don't touch the screen edges. It would 
be the nirvana of usefulness for toolkit authors. That is why I am still 
really insistent that the proposed pointer lock have these TRIVIAL 
modifications:

1. The cursor is not "frozen" during pointer lock, instead it is placed 
at the "hint" position.

2. There is a type of pointer lock that is attached to a mouse-down 
event and is lost when the mouse is released. The reason for this is 
because a compositor will be much more likely to grant such a lock, 
because it is easy for a user to get out of it no matter how misbehaved 
a client is. Therefore clients can assume it will work.

I know this will get ignored, but I still don't understand why. My 
changes are obvious and really useful. All I can think is that Jonas is 
thinking of a single usage for games, and is failing to realize how 
incredibly useful his pointer lock would be in many other cases.

>>> Why are we passing a pointer object here instead of the seat?  If a game
>>> wants relative pointer data it'll likely not want absolute pointer data,
>>> so why does it have to bind an absolute pointer (and receive events on
>>> it?) before it can get the relative stuff it's actually going to use?

The client needs to know where the cursor actually is so it can start 
the relative motion at the right place. So it will need to get absolute 
positions. Also the button events are sent to the pointer.

> Why not just allow the pointer to be bound as either/both serial and
> absolute, and have each be a fully functional interface?

It needs to be able to see both the absolute and relative events without 
a round trip. So it would keep both open and would just get duplicate 
button events.

A simpler solution would be to just make the relative motion be another 
event produced by wl_pointer, or to add extra fields to the motion 
events. Not sure why that solution is ruled out, it seems to be allowed 
when the protocol version changes. The overhead is trivial because the 
absolute event is being sent anyway.