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.
In the legacy mouse reporting mode, line and column numbers are
limited to 223 (255-32). In case the current coordinate falls outside
this, simply ignore it (don't report it).
When support was added for DECOM (absolute/relative row addressing), a
small but noticeable (~3.5%) performance regression was introduced.
Try to improve the situation by simplifying the relative-to-absolute
conversion; only the row needs to be transformed.
The default is absolute mode, where 0,0 is the upper left corner of
the screen.
In relative mode, the origin is relative the top scroll margin.
Internally, we always track the current cursor position in absolute
mode. Every time we the client *sets* or *queries* the cursor position
in relative mode, we translate it to absolute.
A terminal with lots of scrollback history will have allocated a lot
of memory.
Normally, free() wont return this memory to the OS, and we don't seem
to trigger the automatic trim calls.
This means the server would accumulate quite a lot of memory over
time, as terminals come and go.
Now we explicitly trim the memory every time a terminal is destroyed.
Make ptmx non-blocking. Then, when writing data to the slave would
have blocked, use the FDM to asynchronously write the remaining data.
This is done by enabling EPOLLOUT on ptmx, and enqueueing all outgoing
data. The FDM handler will go through the enqueued data, and once all
of it has been written, we turn off EPOLLOUT again (thus switching
back to synchronous writes)
While unusual, it *is* possible for a client *not* to terminate when
we close ptmx.
We need to handle this *somehow*. Since it is so unusual, we'll go
with a fairly easy, but synchronous method:
* Register a signal handler for SIGALRM, and setup a 2 second alarm
* Wait for slave to die
* If it didn't die, sent SIGTERM, then re-set the alarm for another 2
seconds.
* If it still hasn't died, send SIGKILL (this time without an alarm).
When there hasn't been a timeout (or in our case, there was a timeout,
but we reset the timer before we got to the read()), read() returns,
not 0, but -1 with errno == EAGAIN.
Since we cancel the timers every now and then, there's a (small)
chance that one handler cancels a timer that has triggered in the same
epoll() iteration.
When this happens, read() blocks.
Fix by making the timer FDs non-blocking, and simply returning when we
read 0 bytes.
