Apparently, a frame callback for the cursor surface is *never*
triggered if we get a pointer-leave event *before* the callback is
triggered. At least on Sway 1.4.
This caused the cursor being stuck, and never updating once this state
was reached.
Fix by destroying the cursor frame callback on pointer-leave.
This adds a flag, -p,--presentation-timings, that enables input lag
measuring using the presentation time Wayland protocol.
When enabled, we store a timestamp when we *send* a key to the
slave. Then, when we commit a frame for rendering to the compositor,
we request presentation feedback. We also store a timestamp for when
the frame was committed.
The 'presented' callback then looks at the input and commit
timestamps, and compares it with the presented timestamp.
The delay is logged at INFO when the delay was less than one frame
interval, at WARN when it was one frame interval, and at ERR when it
was two or more frame intervals.
We also update statistic counters that we log when foot is shut down.
The mouse reporting functions are called from input when we receive
Wayland mouse events.
We used to pass the current keyboard modifier (shift, alt, ctrl, etc)
to the terminal functions.
This however is wrong, since we may receive Wayland mouse events
without having keyboard focus. When we don't have keyboard focus, the
modifier state doesn't apply to us.
Remove the modifier arguments from the terminal mouse reporting
functions. These functions now read this state directly instead, but
only when the terminal instance in question has keyboard focus.
When we receive a keyboard_key or pointer_motion event without first
having received a keyboard_enter or pointer_enter event (that being
the "sway bugs" part), we generally don't know _which_ terminal window
the event was intended for.
However, if we only have *one* window open (always the case for a
regular 'foot' process, or when there's a single footclient connected
to a foot server process), then obviously we can "guess" which window
the event was intended for... so do that.
Now, the only time the event is ignored is when we're a server process
with more than one window open (= more than one footclient connected).
I.e. what we're effectively doing is *not* repeating modifier
keys.
Besides being the "right" thing to do, this also works around another
Sway 1.2 bug, where being in a focused foot window and then switching
to a vt and back would cause us to be stuck in an endless key repeat
loop that would only stop when unfocusing, focusing back and then
unfocusing once again.
