This tidies up the valgrind output some more, but seems to highlight
some leaks in the egl implementation around init/shutdown.
I still don't see a smoking gun for a memory leak that grows over time.
refs: https://github.com/wez/wezterm/issues/238
I'm wondering if the non-deterministic portion of
refs: https://github.com/wez/wezterm/issues/241
might be due to splitting of data across multiple write calls.
This commit adopts the use of BufWriter around the writer so that
we can buffer up and explicitly flush the responses to the terminal.
When running on a 30bpp display with 2 bit alpha, eglChooseConfig
will match and list the 10bpc configuration first, which don't match
the desired pixel format.
Filter the config list so that it only includes 8bpc configurations.
refs: https://github.com/wez/wezterm/issues/240
In refs: https://github.com/wez/wezterm/issues/240 there are a number
of configurations that report 0 for the alpha size and where we are
unable to otherwise find a working config.
This is a speculative commit to releax the alpha channel size to
basically anything available and see if that helps.
This commit refactors the wayland EGL init code to call into the
non-wayland init code which is more in the spirit of DRY.
It also highlights that we were requesting PBUFFER and PIXMAP capable
contexts in the non-wayland case. Since we appear to survive without
those in the wayland renderer, presumably we can survive without them
in all cases.
This may help with activating opengl for this issue:
refs: https://github.com/wez/wezterm/issues/240
While looking into what it might take to support 10bpc (30bpp) displays
(https://github.com/wez/wezterm/issues/240) I was experimenting with
Xephyr at a reduced 16bpp depth and noticed that the server still
offered a 32bpp TrueColor depth option.
This commit adjusts the window/bitmap code to allow it to select depths
24bpp or 32bpp, preferring the largest depth. we restrict ourselves to
24 and 32 bit selections for this, as those appear to be bit for bit
compatible for the r/g/b channels. I suspect that 10bpc will require
some scaling somewhere.
This change allows running wezterm against the reduced depth Xephyr, but
since Xephyr doesn't support GL it runs with the software renderer; I
don't know quite how opengl is going to play with this. I can confirm
that running wezterm on my native 24bpp display when it picks a 32bpp
visual does run with opengl enabled, so maybe this is good enough?
8f1f1a65ea added support for probing
for opengl extensions, and I thought that I had the fallback covered
but it turned out that we were only falling back if one of the major
extensions wasn't present.
This commit adds a fallback for the case where things look ok at
first glance, but where they fail at runtime for whatever reason.
refs: https://github.com/wez/wezterm/issues/235
viewport changes could do a little bit more than they needed
to when the search overlay was active. Guard against that by
checking to see if the viewport is already set to the new position.
The code assumed that OSC parameters were always numeric, but that isn't
the case.
In order to allow adding non-numeric OSC code we need to adjust and
allow for the codes to be any string value, and that's what this
commit does.
It shouldn't change any other behavior.
This commit adds an overline glyph which is simply a line drawn at
the top of the cell.
Due to the way that we use a single glyph for the line layer, this
actually adds a handful of combination glyphs for the different
underline, overline and strikethrough possibilities.
It's getting a bit hefty. Adding another similar attribute in
the future (eg: maybe wiggly underlines?) might prove to be too
much for the simple approach we have right now.
```bash
printf "\x1b[53moverline\x1b[0m\n"
```
This commit teaches the terminal model about the overline attribute
and the SGR codes to enable/disable overline.
The render layer in the GUI doesn't yet understand this attribute.
This allows setting up shortcuts relative to the final tab in
a window, rather than always being relative to the first.
The default assignment for CTRL+SHIFT+9 is now `ActivateTab=-1`
as a convenient way to always reach the last tab.
refs: https://github.com/wez/wezterm/issues/228
We were unconditionally adding the encoded form of the modifier
mask (eg: appending `;1~` to the sequence) and not all apps know
how to interpret that.
refs: https://github.com/wez/wezterm/issues/227
While testing this with esctest, it was apparent that xterm deviates
from the DEC docs by allowing a minimum region size smaller than 2,
so adjust our restriction accordingly.
Now that we're reporting a higher level from DA1, apps are asking
more exotic codes. eg: vttest now asks about the conformance level,
but doesn't have a timeout on that request and hangs if we don't
respond.
This commit adds a bit of plumbing to make it easier to consume
and parse DCS sequences that are known to be short/short-lived,
and teaches the term layer to respond to a couple of possible
DECRQSS queries.
This is an xterm sequence that adjusts how the terminal
encodes keyboard output.
This commit teaches termwiz to parse and encode the sequence,
but doesn't teach the terminal emulator to do anything with it
at this time.
I'm adding this because vim sends these sequences and I wanted
to understand what they were for.
This commit adds support for left/right margins and has been
tested against esctest, with a final status of:
```
309 tests passed, 239 known bugs
```
"known bugs" also includes unimplemented features; we have a
similar degree as iTerm2.
As of this commit, we now report as a vt520ish machine to DA1.
I confess to not having read enough of the relevant docs
to know whether this is totally righteous.
