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

[Pekka Paalanen]

On Wed, 29 Aug 2012 20:35:34 -0500
Vincent Povirk <madewokherd at gmail.com> wrote:

> > Yup, good points here.  I think we could reuse the wl_pointer
> > interface, but just send relative motion in the motion event and it
> > should go throught the wl_seat capability feature as Daniel describes.
> 
> With this approach, is it going to be possible to know both the
> relative motion for an event and the absolute position the cursor
> moved to? SDL reports both relative and absolute cursor positions in a
> single event, and on Windows I believe this can include relative
> motion even when the cursor is clipped by a screen edge.
> 
> (And anyway, I'm pretty sure Wine needs both relative and absolute
> coordinates to implement the mouse input API's correctly.)

That's a good question.

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.

Btw. there are no absolute pointer coordinates, really. All pointer
coordinates are relative to the current surface.


On Wed, 29 Aug 2012 15:29:44 -0400
Kristian Høgsberg <hoegsberg at gmail.com> wrote:

> I think we can just say that if you have a raw pointer (ie, you've
> called wl_seat_get_pointer_raw), then that takes precedence over the
> normal pointer interface (that is, the normal pointer stops sending
> events).  And the normal pointer needs to send a leave event and the
> relative pointer should send an enter event.  If we alt-tab away, the
> relative pointer sends a leave event.  Mousing over a surface that is
> in relative mode should not "capture" the pointer, only activating the
> surface (either alt-tabbing back, or click-to-focus).  When we mouse
> over the surface, we could either just not send events if the client
> has a raw_pointer, or we could send wl_pointer.enter, motion, and then
> wl_pointer.leave + raw_pointer.enter when the surface is activated and
> we switch to relative motion.

Wonder how well this applies to a client having two surfaces: one with
normal pointer mode and one with raw pointer mode. I guess it's not
really different whether one destroys the raw mode pointer on leave
from raw mode surface, or on enter to normal mode surface.

> I think we may want to keep a pointer surface in raw pointer mode, but
> let the client hide it, if it wants to.

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.

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.


Thanks,
pq