This is still a bit rough because the terminal parser doesn't
understand the pixel sizes, so it relies on the hard coded
cell dimensions being accurate.
This uses the same plumbing as the software frontend, but tries
to enable opengl.
None of the opengl rendering is plumbed through here yet, so this
is currently functionally identical to the software renderer.
Tested only on windows with a USB serial connector to my NUC running
linux.
This allows opening up wezterm on a serial port connection.
Serial is closer to a tty than a pty, so it is a bit different
to configure and use.
This commit allows running:
```
wezterm serial COM3
```
to open a window that connects to the specified COM port.
You can change the baud rate with:
```
wezterm serial --baud 9600 COM3
```
There are more options that could be set, but I'm a bit lazy and
have only exposed the baud rate to the wezterm cli so far.
In the early days we relied upon the bounded length of a sync channel
to put back pressure on the output from a child command. We're no
longer using that kind of channel, so here's a more deliberate and
measurable rate limiting implementation.
The `ratelimit_output_bytes_per_second` configuration setting defaults
to 2MB/s and constrains the amount of text we send to the escape
sequence parser.
This value was selected based on it being a combination of responsive
to ctrl-c while outputing a lot of data and still generating sleeps
to remain within the constraints.
This does mean that terminal benchmarks that test how quickly you
can dump text to the terminal will hit this artifical upper limit
and are thus not going to be a true measure of performance.
It's taking a while for https://github.com/jwilm/vte/pull/20 to get
merged, so point to my branch directly while I build out some
tunneled mux protocol escape sequences.
I'll need to fork vte on crates.io if vte doesn't merge the PR
before the next termwiz crate bump.
This removes some awkwardness in the impl by allowing casting
to a concrete implementation. This is a pattern I want to use
more widely and this diff proves the concept.
When enabled, the windows version will use winpty rather than conpty.
This potentially allows running on older windows versions but has
a few caveats:
* Requires winpty.dll and winpty-agent.exe be in the PATH
* The initial screen / cursor position looks funky for me with the
latest release of winpty, but that is from a couple of years ago
* Mouse reporting doesn't work, perhaps for the same reasons that
it isn't working in conpty.
I want to make this into a runtime selectable feature before tidying
up the installation aspects; we need that plumbing anyway to be
able to select between local and remote mux'd tabs.
This is primarily for macos where the default freetype
installation is unable to render color emoji, but should also
help make things more consistent across the various platforms.
It's a little bit awkward on linux because the font-loader crate
pulls in the now-conflicting servo-font* crates. I've disabled
font-loader on linux systems; it's just calling fontconfig under
the covers anyway.
Reduces the size of the full screen serialized size from 40k -> 13k.
Note that the `zlo` crate (which doesn't appear to have a repo
on github any longer; sources are only found in the crates.io
documentation source view), employes zigzag encoding of all integers
and floating point values and takes the size down to just under 10k.
A todo is to follow up on that and see if we could adopt the same
scheme in varbincode.
The `directories` crate unconditionally and eagerly tries to spawn
`xdg-user-dir` for all possible directories that it might be asked
about. This is relatively expensive and undesirable.
Shift to the `dirs` crate instead, which doesn't seem to need
to run `xdg-user-dir` at all.
Maintain these probed dirs as singletons via lazy_static.
Remove detailed xcb select event hack
Only remove consumed "mod5" for now
which is AltGr.
Get actual modifiers from xkb.
it should enable 1:1 match with user's xmodmad
[clippy] allow keys deadcodes
handle mods & keys separately. Allows passing down `ctrl+2`
state.key_get_utf8 will interpret ctrl+2 (or @, space, ~) to 'ctrl \u{0}'
no need to wait for events.
+ Send delete as enum variant not by char value
Hook XKeysym to termwiz::KeyCode
prefer dealing with chars instead of utf8
Actually this breaks multi unicode characters .. such as J́
Others can be found with
perl -lane '/"\s+#/ && print' < /usr/share/X11/locale/en_US.UTF-8/Compose
Anyway we will need to return a Vec of chars for those.
cleanup
apply rustfmt
query locale via libc
This removes some tricksy code in favor of a third party crate,
which unlocks the clipboard on windows. I'm not sure how well
this will work on the pure x11 impl yet.
I wasn't pleased with how text was rendering on a colored background,
and after some research I discovered that I was neglecting to convert
from sRGB to a linear RGB colorspace, and that this was causing the
blending to have inaccurate results.
This diff pulls in the palette crate to handle the heavy lifting.
It doesn't appear to have any especially fast optimizations for this
though, which is a shame because the blending code I was using
previously was largely integer math with few branches. The colorspace
conversion has several floating point operations and branches that
are unavoidable :-/
We run a bit hotter on the CPU but the results are much more pleasing
to the eye.
So that we no longer assume Operator Mono SSm.
We now default to `monospace`. I just tried this and the font metrics
appear to be wonky, so there's some tweaking to do.
This eliminates the zsh reversed % artifact issue.
Added a feature flag to turn on diagnostics even in release mode;
`cargo run --release --features debug-escape-sequences`
Using the SHM extension of the X server saves us from sending ~1MB of
bitmap data to the server on many screen update operations for a
modestly sized terminal window.
SHM may not be available in some situations so we need to keep a
fallback that basically works. This is done via a helper enum
in xwin.rs.
I've removed the unused Pixmap class; the pixmap concept makes the
most sense for us only when SHM is available.
The spacing between glyphs seems too wide. Need to figure this out.
A bunch of the integer vs float changes in this diff were a result
of trying to run this down, but success has been limited, and in fact
the spacing has increased as a result of making this more correct(!)
Initially I wanted to make the font code separate from
the main wterm executable in the hope that it would be
reusable. However, we do need to be able to reach in
to both the font implementation and the SDL texture
implementation in order to capture the glyph data
into textures, so let's just embrace it all being
in the same crate.
Trigger x-scaling based on the x_advance rather than the bitmap width.
Also account for the unicode width of the fragment when scaling.
The use of bearing_x was incorrect; we were subtracting it rather
than adding it and making the glyphs look terrible at smaller sizes.
