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.
