This allows moving past a number of outdated deps, but importantly,
allows updating miow to a version that has the correct memory layout
for SocketAddr, and satisfies a dependabot alert.
This appeases some dependabot warnings regarding the use of
an old version of parking_lot that has some unsoundness issues.
ratelimit_meter is frozen and is succeeded by governor which has
a mostly similar API.
The hope here is that the nvidia-specific resize issue might have
a workaround if it is emitting some other events that we were
previously not listening for.
This commit optionally enables the Present extension and listens
for its version of CONFIGURE_NOTIFY, routing it through the same
logic as the base CONFIGURE_NOTIFY event.
On my AMD hardware under Gnome, I see something like:
```
18:04:26.476 TRACE window::os::x11::window > Present::ConfigureNotify: width 1168 -> 1180, height 858 -> 873, dpi 124.7998046875 -> 124.7998046875
18:04:26.478 TRACE window::os::x11::window > Ignoring X::ConfigureNotify (1180x873 dpi=124.7998046875) because width,height,dpi are unchanged
```
with the Present event firing before the X event.
Let's see how this goes.
refs: #2063
refs: #1992
My windows build didn't work this morning, complaining:
; cargo build
Updating crates.io index
error: failed to select a version for the requirement `libgit2-sys = "^0.13.4"`
candidate versions found which didn't match: 0.13.2+1.4.2, 0.13.1+1.4.2, 0.13.0+1.4.1, ...
location searched: crates.io index
required by package `git2 v0.14.4`
... which satisfies dependency `git2 = "^0.14"` (locked to 0.14.4) of package `config v0.1.0 (C:\Users\wez\wez-personal\wezterm\config)`
... which satisfies path dependency `config` (locked to 0.1.0) of package `codec v0.1.0 (C:\Users\wez\wez-personal\wezterm\codec)`
... which satisfies path dependency `codec` (locked to 0.1.0) of package `wezterm v0.1.0 (C:\Users\wez\wez-personal\wezterm\wezterm)`
The cargo update downgraded the dep, but looking at crates.io the
requested revs look ok. Something is fishy.
I upgraded rust and ran cargo update again to get back on the
same git rev, so now this commit captures the other things
that changed.
Avoid using serde for mapping between Lua and Rust for the `Config`
struct.
This improves the build speed of the config crate by 2x; it goes down
from 30 seconds to 9 seconds on my 5950x.
This cleans up the `cargo audit` output on linux because the `clipboard`
crate (which hasn't been updated in 3 years) depends on xcb=0.8.2
which is flagged by cargo audit.
We don't use `clipboard` on any platform except macos
This commit switches to the `clipboard_macos` crate; that appears to
use a copy and paste of the macos specific code from the `clipboard`
crate, so this shouldn't have any change in functionality.
refs: https://github.com/wez/wezterm/issues/1952
I think I'd like to make a config option for this, but for the moment,
this first pass unconditionally updates the base environment with
data from the registry.
refs: https://github.com/wez/wezterm/issues/1848
Use some heuristics to verify the data that is about to be parsed;
this can help to detect eg: data being output to stdout prior
to us sending any encoded data to the remote mux.
In addition, add a timeout to help avoid waiting forever in
the case that we didn't detect a problem.
refs: https://github.com/wez/wezterm/issues/1860
I wanted to use the Target::Pipe feature of env_logger so that we could
log to a log file as well as stderr, but it just doesn't work
(https://github.com/env-logger-rs/env_logger/issues/208).
Since we were already composing over the top of the logger in order
to capture data for our ringlog, this commit embraces that and makes
our logger responsible for both stderr and log file printing.
Thankfully, we can use the filter parsing code from env_logger to
avoid having to get too crazy with this.
Logs are stored in the runtime directory and look something like:
/run/user/1000/wezterm/wezterm-gui-log-596324.txt
Logs are collected on all platforms.
There isn't currently a thing to clean up logs.
Go directly to the underlying env_logger crate, as pretty_env_logger
hasn't been updated in some time, and I'd like to be able to redirect
the log output to a file more directly, and that feature is in a newer
version of the env logger than pretty_env_logger was pulling in.
We were pinned on the revision where I had added dual source blending,
because I wanted that feature ahead of the crate being published.
Since then a couple of releases have been made so we can unpin.
On Windows 11, we had a report of glium complaining about the opengl
version. I can't find that error message string in the current version
of the code so it's possible that that situation has been resolved.
refs: https://github.com/wez/wezterm/issues/1813
* termwiz: add support for kitty image using shm mode
* termwiz: kitty image shm cleanup error handling
* termwiz: kitty image shm create wrapper for HANDLE and impl Drop for it
* termwiz: kitty image shm refactor windows implementation
Signed-off-by: Shreesh Adiga <16567adigashreesh@gmail.com>
There were a a couple of issues:
* `ImageData::hash` would re-hash the image on every call, and this was
called for every cell that comprised an image on the mux server side
* `SerializedLine` needed to understand how to remove the `Arc<ImageData>`
image attachments so that we didn't serialize a complete copy of the
image per cell that comprised the image.
A new RPC was introduced to attempt to fetch `ImageData` given its
content hash and pane, row and cell index as a hint to locate it.
A client side LRU of content hash to `ImageData` is used to avoid
issuing repeat calls to that new RPC.
refs: #1237
