We handle this with a temporary buffer for the upload, which is
a little gross but avoids leaking that implementation aspect
out to the rest of the code.
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.
Since we don't have a draw-image-and-rescale primitive, and since
we'd have to scale every time we drew the glyph, it makes sense to
cache the pre-scaled glyph in the atlas.
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.
Previously we had the logic for this in wezterm itself; it would know
how to figure out which shell to run, or whether we should run a
different program by default (the `default_prog` setting).
This was OK, but when I added support for ssh we hit a conceptual
issue: the local side of the ssh session doesn't have any information
about the shell that should be invoked on the remote side and instead
needs to ask the remote to figure that out. The interfaces defined
in the code didn't allow for this.
This commit formalizes the concept of a default program and allows
it to be carried through to the pty layer, including over ssh sessions.
Since we now have enough smarts to figure out the local shell and the
local home dir, I've removed the logic that run `login -pf` on macos
by default; this should make the terminal startup very slightly faster
on macos, but since I'm currently on a windows system, I can only test
linux and windows on this side of this commit. I'll follow up on macos
later.
This makes it a bit more convenient to control when and which
multiplexer(s) you want to connect to.
Now that each domain must have a name in the configuration file,
we can address them more conveniently from the command line.
This is mostly useful for folks on Windows, as you can also run
`wezterm start ssh user@host some command` to run the `ssh` binary in a
local pty and let it manage your ssh session.
On Windows the local pty currently breaks mouse reporting
(see https://github.com/microsoft/terminal/issues/376) so it is
desirable to avoid using a local pty if we're going to talk to a
remote system.
This commit makes it a bit more convenient to establish an ad-hoc ssh
session with a pty on a remote host. This method uses libssh2 under the
covers and thus doesn't support gssapi, which is potentially frustrating
for kerberized environments, but works ok for the majority of users.
There are two issues that I want to resolve in follow up work:
* The TERM has to be sent very early in the channel establishment,
before we "know" the TERM in the `portable-pty` interface. Will need to
figure out how to specify that earlier in an appropriate way.
* Similarly, if no command is specified, we should request the use
of the shell subsystem but we don't have a way to capture this
intend with the cmdbuilder. Will need to solve this too.
They don't always work, so let's just not use them when under wsl.
Since we now know how to detect when we're running under wsl, we
can use that knowledge to bypass permission checking for the unix
domain sockets automatically too.
This helps diagnose problems where stderr is not visible.
Let's also capture them to the `log` stream too, and clarify
toml parsing errors, and fix the underlying problem with
ssh_domains not being allowed to be left unspecified.
I was too focused on the wsl case and didn't test this. We can't
redirect the process handles without causing some problems with
starting up cmd.exe. Comment out that portion of the code for
the moment.
This adds some plumbing so that a domain can indicate whether it is
attached or not, but is not yet smart enough to detect a closed
connection and mark itself as detached.
The sync_channel was originally added as a brake to avoid swamping
the event loop, but we've subsequently grown a more formal rate
limiting config for this.
The rate limiter is superior because it allows making forward
progress over time, whereas the bounded channel is a hard blocking
limit.
When making a large paste the app on the other end will typically
emit a lot of output. If our reader is blocked on the sync channel
the output of the pty can be blocked, and that in turn will block
our attempt to write to the pty.
We cannot simply set the pty to non-blocking mode because non-blocking
ptys are not a thing on windows, and in the interest of not silently
breaking windows, I prefer to make the unix side of things match
that architecture.
anyway: TL;DR is that we don't need the bounded channel now that
we have rate control to manage swamping the event loop, so we
can simplify this code.
For unix and tls clients, if connect_automatically is set
and we're not running the server, then instantiate and connect
to those domains when we start the app.
As part of this I realized that we weren't mapping the remote
tab to the local tab for unilateral pushes, so add some stuff
to support that.
cmd-t now spawns in the same domain as the active tab,
cmd-shift-t spawns in the default domain.
It is possible to define bindings to spawn in an arbitrary domain.
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.
This removes some redundancy and overhead around setting up the
connection (the native_tls crate doesn't provide PEM functions,
despite every deployment I've ever seen only ever using PEM certs),
but more importantly, gives the control needed to make hostname
verification work in a PKI setup with unusual CN values.
