[PATCH wayland] Add a relative_grab request to the wl_shell_surface interface

[Vincent Povirk]

> wl_pointer::enter event carries x,y, so even for relative pointer
> mode, it can tell at which point on the surface the pointer comes in.
> After that, the application can accumulate relative events to know the
> position inside the surface.
>
> Except that won't really work. I believe the relative events are also
> supposed to be raw events. The normal pointer mode OTOH uses
> accelerated or otherwise modified coordinates, so accumulating raw
> coordinates will differ from the server's idea of pointer position.

So really there are three kinds of events that an application might
want: raw, relative to the previous position and not clipped, and
relative to the surface and clipped. In an emulator where the mouse
input is passed to some other system that's going to apply its own
acceleration, you would want raw events. You could also use relative
mouse input to simulate a larger canvas than the screen can display,
by automatically scrolling when the cursor moves beyond the screen
edge, in which case you want the relative coordinates with
acceleration applied (in addition to normal coordinates). (Even for
normal applications that idea could be useful for selecting things
beyond the visible bounds of a text box. Currently most toolkits
simulate it badly by scrolling at a rate based on how far the cursor
is from the boundaries of the text box.)

> What use could the pointer surface possibly have in raw/relative pointer
> mode?
>
> It will not correspond to any position known to a client, for
> the reasons I wrote above on raw vs. normal coordinates. I can't see a
> way to have the cursor in a meaningful position.

It would be useful in cases like the one I described where you really
want both types of coordinates.

> Would you clip the cursor (surface) position to the surface that uses
> raw pointer mode or not? If not, the server's vs. client's idea of
> pointer position will mismatch the moment the server first clips
> pointer motion to the output regions.

I think the type of input events you want is an entirely separate
question from whether you want the cursor clipped. You might want to
clip the cursor to a surface even when getting normal pointer events,
for example in a game where you want to prevent the user from
accidentally clicking outside your window. (This also means that the
area you want to clip to isn't necessarily the full size of your
surface, since you might want to prevent the cursor from moving over
your window decorations.) The reverse seems unlikely (since the range
of motion for your relative events is arbitrarily limited by the size
of your non-fullscreen surface), but maybe you only really care about
relative events when the user is holding a mouse button, giving you an
implicit grab.