wl_display_dispatch() calls poll(), which is unnecessary since we
already know the FD is readable.
Use the more lower level wl_display_read_events() +
wl_display_dispatch_pending().
These require wl_display_prepare_read() to have been called.
The idea is to call wl_display_prepare_read() **before** calling
poll().
Thus, we do this more or less last in wayl_init(), and at the **end**
of the FDM handler.
However, having taking this lock also means we no longer can call
wl_display_roundtrip() directly (it will hang).
So, add a wrapper, wayl_roundtrip(), that cancels the read intent,
does the roundtrip, and then re-acquires the read intent.
Instead of having `wayl_win_init()` call
`wl_display_roundtrip()` (which it itself doesn't need), call it from
`term_init()`.
This allows us to add ourselves (the new terminal instance) to the
terminal list in the wayland backend, before triggering the wayland
events caused by `wayl_win_init()`.
This is turn allows the wayland backend to find/lookup the new
terminal when those events occur..
This allows us to measure the time between to refresh delays. That is,
when we decide to delay a refresh, we store the current time.
If we hit that code path _again_, without having refreshed, we
calculate the time that has passed.
This gives us an estimate for how we should set our lower delay
timeout.
This is of course application dependent, but is still much better than
simply guessing a value...
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.
This is used when spawning the slave, to set its current working
directory just before we exec() the client.
In a regular foot instance, we set the cwd from getcwd().
In a foot server instance, each connecting client sends its cwd to the
server, and we use that.
Increase the low timeout, to try to give clients/slaves more time to
emit data.
Decrease the upper timeout. On average, we should have ~½ frame left
until the next frame. So a maximum delay of a whole frame *will* delay
the update one extra frame in many cases.
Hopefully, the low timeout is still low enough that we don't miss the
next frame, on average.
Instead of trying to figure out if we had to render
something (i.e. something in the grid was dirty), and using that to
determine whether to post a callback or not, we now let
render_refresh() set a flag indication we need to render another
frame.
This simplifies render_grid(), which now _always_ renders, and pushes
it to the compositor.
The callback handler checks the pending flag and simply doesn't call
render_grid() when there's no more pending state to render.
This ends up reducing the number of wakeups when e.g. having a
blinking cursor.
Normally we don't dirty the cell on cursor movement. But, since a
blinking cursor isn't a cursor that has moved, our normal cursor
rendering wont work.
Dirty the cursor cell to force a redraw of it.
Blinking can be enabled either by setting the cursor style with
CSI Ps SP q
and selecting a blinking style.
Or, with 'CSI ? 12 h'
Note that both affect the same internal state. I.e. you can disable
blinking with CSI ? 12l after having selected a blinking cursor
style. This is consistent with XTerm behavior.
In most cases (i.e. when there's only a single output/monitor), this
will be *the* DPI value.
In other cases, well...
The _right_ thing to do is track the outputs our window is actually
mapped on, and re-instantiate fonts depending on the current output's
DPI. But that's for the future...
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 this returns true, it means we have keyboard focus and are
grabbing the mouse (for e.g. selections), regardless of whether the
client has enabled mouse tracking or not.
Instead of duplicating the code from selection_enabled() that deals
with forced selection, just call selection_enabled().
This was previously not possible since selection_enabled() didn't
require keyboard_focus. Now it does.
Show 'text' cursor when:
* we have no mouse tracking enabled
* forced selection has been enabled (shift being held down)
* We're *not* scrollback searching
In all other cases, show the 'left_ptr' cursor.
When trying to write (to e.g. the slave, or to a clipboard receiver),
we first try to send the data synchronously, and only if that fails do
we switch to asynchronous mode.
However, the first synchronous may (in fact, is likely to) succeed
partially.
When we're shutting down a terminal, we destroy our Wayland window,
and assume that will unmap us.
There are cases when this isn't true (most likely when e.g. a screen
locker is active, and the unmap is being deferred).
Handle by explicitly setting focused to NULL.
