In 3a2eb80d83, we fixed an issue where
key *releases* triggered a selection reset, and viewport reset.
The same issue still exists in other input modes (unicode, search and
url mode); if the kitty keyboard protocol has been enabled, with
release events, any key press directed to e.g. search input handling,
will was not remembered, and the corresponding release event generated
a kitty keyboard event to the terminal application, and reset the
viewport and selection.
This means, for example, that scrollback search was unusable.
Fix by *never* doing any further (generic) key processing if an
alternate input mode is active.
Closes#2316
When writing paste data to the terminal (either interactively, or as
an OSC-52 reply), we enqueue other data (key presses, for examples, or
query replies) while the paste is happening.
The idea is to send the key press _after_ all paste data has been
written, to ensure consistency.
Unfortunately, we only checked for an on-going paste. I.e. where the
paste itself hasn't yet finished. It is also possible the paste itself
has finished, but we haven't yet flushed all the paste buffers. That
is, if we were able to *receive* paste data faster than the terminal
client was able to *consume* it. In this case, we've queued up paste
data in the terminal. These are in separate queues, and when emitting
e.g. a key press, we didn't check if all _those_ queues had been
flushed yet.
Closes#2307
The pre-apply damage thread may be running when we destroy a terminal
instance, and we need to wait for it to finish before destroying the
underlying buffer.
c291194a4e did this, but failed to
realize the thread may get re-started in the roundtrips done later in
wayl_win_destroy(); after the wait added in
c291194a4e, we unmap all
surfaces (including the main grid), and roundtrip. This means the
compositor will release the currently active buffer, and that means
_we_ will trigger the pre-apply damage thread on it. This introduces a
race, where wayl_win_destroy() may reach its shm_purge() calls before
the pre-apply damage thread has finished. That typically causes foot
to crash.
Closes#2288
Recent clang versions warn on __COUNTER__, unless compiling with
-std=c2y (which breaks other things).
"Fixes" '__COUNTER__' is a C2y extension (__COUNTER__ is used by our
UNITTEST macro).
This patch adds a new config option: colors{,2}.blur=no|yes. When
enabled, transparent background are also blurred.
Note that this requires the brand new ext-background-effect-v1
protocol, and specifically, that the compositor implements the blur
effect.
It's possible, but unlikely, that we've pushed a "pre-apply damage"
job to the renderer thread queue (or that we've pushed it, and the
a thread is now working on it) when we shutdown a terminal instance.
This is sometimes caught in an assertion in term_destroy(), where we
check the queue length is 0. Other times, or in release builds, we
might crash in the thread, or in the shutdown logic when freeing the
buffer chains associated with the terminal instance.
Fix by ensuring there's no pre-apply damage operation queued, or
running, before shutting down a terminal instance.
Closes#2263
Applications often prefix the sixel with a raster attributes (RA)
sequence, where they tell us how large the sixel is. Strictly
speaking, this just tells us the size of the area to clear, but we use
it as a hint and pre-allocates the image buffer.
It's important to stress that it is valid to emit a MxN RA, and then
write sixel data outside of that area.
Foot handles this, in _most_ cases. We didn't handle the corner case
Mx0. I.e. a width > 0, but height == 0. No image buffer was allocated,
and we also failed to detect a resize was necessary when the
application started printing sixel data.
Much of this is for performance reason; we only check the minimum
necessary. For example, we only check if going outside the
pre-allocated *column* while printing sixels. *Rows* are checked on a
graphical newline.
In other words, the *current* row has to be valid when writing
sixels. And in case of Mx0, it wasn't.
Fix by forcing a height of at least one sixel (typically 6 pixels).
Closes#2267
This fixes an issue with the kitty keyboard protocol, where 'release'
events associated with a shortcut was sent to the client application.
Example: user triggers "scroll up". We scroll up. No key event(s) are
sent to the client application. Then the user releases the keys. we
don't do any shortcut handling on release events, and so we continue
with the normal input processing. If the kitty keyboard protocol has
been enabled (and specifically, release event reporting has been
enabled), then we'll emit a 'release' escape sequence. This in itself
is wrong, since the client application never saw the corresponding
press event. But we _also_ reset the viewport. The effect (in this
example), is that it's impossible to scroll up in the scrollback
history.
Note that we don't ignore _any_ release event, only the release event
for the (final) symbol that triggered the shortcut.
This should allow e.g. modifier keys release events to be processed
normally, if released before the shortcut key.
This is somewhat important, since the client application will have
received press events for the modifier keys leading up to the
shortcut (if modifier press/release events have been enabled in the
kitty keyboard protocol - _Report all keys as escape codes_).
Closes#2257
Without this, the input handling code won't understand the key/mouse
event was consumed (i.e. triggered a shortcut), and will continue
processing normally (e.g. sending event to the client application).
Before this patch, foot used xrgb surfaces for all fully opaque
surfaces, and only used argb surfaces for the main window when the
user enabled translucency.
However, several compositors have damage-like issues when we switch
between opaque and non-opaque surfaces (for example, when switching
color theme, or when toggling fullscreen).
Since the performance benefit of using non-alpha aware surfaces are
likely minor (if there's any measurable performance difference at
all!), lets workaround these compositor issues by always using argb
surfaces.
Otherwise, a sequence like
\E[4:2;4m # Enable double-underline, then immediately switch to single
Will switch to the slow printer, and then get stuck there even though
we immediately switch to plain underlines (which don't need the slow
printer).
The main reason for having two color sections is to be able to switch
between dark and light. Thus, it's better if the section names reflect
this, rather than the more generic 'colors' and 'colors2' (which was
the dark one and which was the light one, now again?)
When the second color section was added, we kept the original name,
colors, to make sure we didn't break existing configurations, and
third-party themes.
However, in the long run, it's probably better to be specific in the
section naming, to avoid confusion.
So, add 'colors-dark', and 'colors-light'. Keep 'colors' and 'colors2'
as aliases for now, but mark them as deprecated. They WILL be removed
in a future release.
Also rename the option values for initial-color-theme, from 1/2, to
dark/light. Keep the old ones for now, marked as deprecated.
Update all bundled themes to use the new names. In the light-only
themes (i.e. themes that define a single, light, theme), use
colors-light, and set initial-color-theme=light.
Possible improvements: disable color switching if only one color
section has been explicitly configured (todo: figure out how to handle
the default color theme values...)
299186a654 introduced a regression,
where we don't handle SHM buffer "hiccups" correctly.
If foot, for some reason is forced to render a frame "too soon", we
might end up having multiple buffers "in flight" (i.e. committed to
the compositor). This could happen if the compositor pushes multiple
configure events rapidly, for example. Or anything else that forces
foot to render something "immediately", without waiting for a frame
callback.
The compositor typically releases both buffers at the same time (or
close to it), so the _next_ time we want to render a frame, we
have *two* buffers to pick between. The problem here is that after
299186a654, foot no longer purges the
additional buffer(s), but keeps all of them around. This messes up
foot's age tracking, and the _next_ time we're forced to pull two
buffers (without the compositor releasing the first one in between),
we try to apply damage tracking that is no longer valid. This results
in visual glitches. This never self-repairs, and we're stuck with
visual glitches until the window is resized, and we're forced to
allocate completely new buffers.
It is unclear why 299186a654 stopped
removing the buffers. It was likely done early in the development, and
is no longer needed. So far, I haven't noticed any bugs by
re-introducing the buffer purging, but further testing is needed.
