[PATCH v3] compositor: send a pointer motion if the focus surface moves under the pointer

[Bill Spitzak]

On 02/28/2013 12:26 AM, Pekka Paalanen wrote:
> On Wed, 27 Feb 2013 16:01:18 -0500
> Kristian Høgsberg <hoegsberg at gmail.com> wrote:

>> Using weston_compositor_get_time() here is problematic (we need to get
>> rid of that function, it's always problematic...).  Input events come
>> with their own timestamp, which are CLOCK_MONOTONIC, while
>> weston_compositor_get_time() is based on gettimeofday().  Motion
>> events and button clicks corresponds to somebody actually moving the
>> pointer and we have evdev events with kernel timestamps for those.
>> The timestamps are there to allow application reason about the timing
>> of "real world events" like time of a double click or pointer speed.
>>
>> Whenever we have to "make up a timestamp" there's something wrong.
>> The reason enter and leave don't have timestamps is that they can
>> happen in response to windows getting mapped or unmapped, which can
>> happen whenever a clients decides to unmap its window.  So there's no
>> inherent timestamp and not always corresponding pointer motion
>> involved (and if there is, a motion event with timestamp will follow).
>>
>> I wonder if we're better off sending a leave/enter pair here, since
>> that doesn't need a timestamp and doesn't imply that the pointer
>> moved.
>
> Hmm, leave/enter pair... we will probably have a leave/enter pair
> also when focus moves from a sub-surface to another surface of the same
> window. How do we guarantee, that a client does not repaint in between,
> to avoid a flash? Especially when keyboard focus moves within a
> window.

Send an extra enter event without any leave event.

In reality enter/leave events don't have to be very accurate. Any 
toolkit that has subwidgets that are unknown to wayland will immediately 
throw away the fact that an event was an "enter" and will pass it 
through the same code as move events are to find out which subwidget is 
to be entered. Such a toolkit does not care if it receives exactly one 
enter event for every leave event.

Perhaps the events should be like this:

MOVE: send when an actual evdev event is translated into motion of the 
pointer on the surface. This is sent for "enter" as well: if the toolkit 
thinks the pointer was outside, it can handle this internally as an 
"enter" followed by a "move". I really would not send both ENTER and 
MOVE, in my work on X and Windows I was forced to use a timeout to 
ignore the extra ENTER events, since just like Wayland the move events 
were the ones with accurate time stamps and positions.

ENTER: sent for any other reason that the compositor wants to inform a 
surface that the pointer is on it. There is no guarantee that the 
pointer has really moved, as that is really hard to figure out. May be 
sent repeatedly to the same surface. A valid (though not ideal) version 
just sends ENTER 20 times a second to whatever surface has the pointer. 
Does not have a timestamp.

LEAVE: Before sending a MOVE or ENTER to any surface, the compositor 
sends this event to the previous surface it sent MOVE or ENTER to.  This 
is easy for the compositor to keep track of. Also has no timestamp. It 
should have the mouse position relative to the surface the event is sent 
to (ie a position outside it's area, or in an location that is clipped 
off by another surface).