On Wed, 29 Aug 2012 20:35:34 -0500 Vincent Povirk <[email protected]> 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 <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
