This fixes an issue where other data (such as replies to other
requests) being interleaved with the OSC-52 reply.
The patch piggy backs on the already existing mechanism for handling
regular pastes, where other data is queued up until the paste is done.
There's one corner case that won't work; if the user *just* did a
normal paste (i.e. at virtually the same time the application
requested OSC-52 data), the OSC-52 request will return an empty reply.
Likewise, if there are multiple OSC-52 requests at the same time, only
the first will return data.
Closes#1734
Don't retry memfd_create() without MFD_NOEXEC_SEAL is 0.
The overall logic is this:
* Try memfd_create() with MFD_NOEXEC_SEAL
* If that fails (which it does, on older kernels), try without the flag
If compiling against an older kernel, or on a system that doesn't
support the noexec seal, MFD_NOEXEC_SEAL is 0.
In this case, there's little point in retrying memfd_create a second
time, with the exact same set of flags.
Don't re-create the single-pixel buffer, unless necessary.
The buffer itself doesn't have a size. That means we can re-use the
buffer if the last frame's overlay style matches the current frame's
style.
What we *do not* know is whether the current frame's size is the same
as the last frame's.
This means we still have to set the viewport destination, and commit
the surface.
The unicode-mode, and flash overlays are single color buffers. This
means we can use the single-pixel buffer protocol.
It's undefined whether the compositor will release the buffer or not;
to make things easier, simply destroy the buffer as soon as we've
committed it.
Note that since compositors don't necessarily release single-pixel
buffers, we can't plug them into our own buffer interface. This means
we can't use buffer pointers to check if we can re-use the previous
buffer (i.e. we can skip comitting a new buffer), or if we have to
create a new one.
It's _almost_ enough to just check if the last overlay style is the
same as the current one. Except that that doesn't take window resizes
into account...
This fixes an issue where entering unicode-mode in one foot client,
also enabled unicode-mode on other foot clients. Both
visually (although glitchy), and in effect.
The reason the state was originally in the seat objects, was to fully
support multi-seat. That is, one seat/keyboard entering unicode-mode
should not affect other seats/keyboards.
The issue with this is that seat objects are Wayland global. Thus, in
server mode, all seat objects are shared between the foot clients.
There is a similarity with IME, which also keeps state in the
seat. There's one big difference, however, and that is IME has Wayland
native enter/leave events, that the compositor emits when windows are
focused/unfocused. These events allow us to reset IME state. For our
own Unicode mode, there is nothing similar.
This patch moves the Unicode state from seats, to the terminal
struct. This does mean that if one seat/keyboard enters Unicode mode,
then *all* seats/keyboards will affect the unicode state. This
potential downside is outweighed by the fact that different foot
clients no longer affect each other.
Closes#1717
That is, instead of sometimes replying with a "source" encoded
string (where e.g. '\E' are returned just like that, and not as an
actual ESC), always unescape all string values.
This also includes \n \r \t \b \f \s, \^ \\ \ \:, as well as ^x-styled
escapes.
Closes#1701
A compositor may unmap, and then remap the window, for example when
the window is minimized, or if the user switches workspace.
With DPI aware rendering, we *need* to know on which output we're
mapped, in order to use the correct DPI. This means the first frame we
render, before being mapped, always guesses the DPI.
In an unmap/map sequence, guessing the wrong DPI means the window will
flicker.
Fix by stashing the last used DPI value, and use that instead of
guessing.
This means the *only* time we _actually_ guess the DPI, is the very
first frame, when starting up foot.
Changing pan/pad changes the sixel's aspect ratio. While I don't know
for certain what a real VT340 would do, I suspect it would change the
aspect ratio of all subsequent sixels, but not those already emitted.
The way we implement sixels in foot, makes this behavior hard to
implement. We currently don't resize the image properly if the aspect
ratio is changed, but not the RA area. We have code that assumes all
sixel lines have the same aspect ratio, etc.
Since no "normal" applications change the aspect ratio in the middle
of a sixel, simply disallow it, and print a warning.
This also fixes a crash, when writing sixels after having modified the
aspect ratio.
In some cases, a sixel may be resized vertically, while still having a
zero-width. In this case, the resize operations are short-cutted, and
no actual allocations are done.
However, we forgot to set 'alloc_height' when doing so. As a result,
the trimming code (when the sixel is "done"), trimmed away the entire
sixel.
When auto-wrap is disabled, a multi-column character may be printed on
a line that doesn't fit the entire character. That is, the "spacers"
we print, as place holders in the columns after the first one, may
reach outside the grid.
We did (try to) check for this, but the check was off by one. Meaning,
we could, in some cases, print outside the grid.
We deviate slightly from the specification, in that we don't assume a
preferred buffer scale of 1. Instead, we "guess" the scale *until we
receive a surface_preferred_buffer_scale event.
Because of this, we don't need the has_wl_compositor_v6 member, as
it's enough to check if we have a non-zero 'preferred buffer scale'.
