wezterm
wezterm copied to clipboard
wez
Wezterm has slow response and even freeze
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Hyprland
WezTerm version
20230305-221833-55982436
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
The response to keyboard typing or navigation is unpredictably slow, sometimes I have to wait few seconds to make it response or need to focus on other windows
To Reproduce
OS: Arch Linux x86_64 Kernel: 6.2.2-arch1-1 Shell: bash 5.1.16 DE: Hyprland Terminal: WezTerm CPU: Intel Pentium G4560 (4) @ 3.500GHz GPU: Intel HD Graphics 610 GPU: NVIDIA GeForce GT 1030 Memory: 998MiB / 14820MiB
I just installed the Archlinux with vanilla Hyprland The only significant thing I did with the system is install nvidia-dkms and add some varibles on /etc/environment
XDG_CURRENT_DESKTOP=Hyprland XDG_SESSION_TYPE=wayland XDG_SESSION_DESKTOP=Hyprland
LIBVA_DRIVER_NAME=nvidia XDG_SESSION_TYPE=wayland GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidia WLR_NO_HARDWARE_CURSORS=1
in /etc/mkinitcpio.conf add nvidia nvidia_modeset nvidia_uvm nvidia_drm to your MODULES
run # mkinitcpio --config /etc/mkinitcpio.conf --generate /boot/initramfs-custom.img
add a new line to /etc/modprobe.d/nvidia.conf (make it if it does not exist) and add the line options nvidia-drm modeset=1
Configuration
no config
Expected Behavior
The typing should be fast response but sometimes the text did not follow as I typed within milliseconds
Logs
Debug Overlay wezterm version: 20230305-221833-55982436 x86_64-unknown-linux-gnu Window Environment: Wayland OpenGL version: NVIDIA GeForce GT 1030/PCIe/SSE2 4.6.0 NVIDIA 525.89.02 Enter lua statements or expressions and hit Enter. Press ESC or CTRL-D to exit 19:17:49.707 WARN wezterm_term::terminalstate::performer > Unhandled OSC 1337 SetUserVar=c2xrZGpmIGRrZmogbGthZGpmYQ===
Anything else?
No response
As a workaround, I'm now using the integrated GPU from my AMD GPU to render wezterm, which works like a charm :smiling_face_with_three_hearts:
I'd assume the same would be possible with an Intel CPU.
@topaxi I tried front_end = "Software" (all the options actually), but none seemed to fix for me :confused:
I guess I'm going to switch to foot until it's fixed
@topaxi @carschandler Are you guys using nVidia + Hyprland/Wayland as well?
My environment is similar to @nghiaxsm, except I'm running on FreeBSD. I'm trying to figure out if the issue is closer to the hardware or if it's higher up in the stack.
I suspect it's an issue between wlroots and the nVidia driver, unfortunately. I tried playing around with nVidia+Hyprland environment variables to see if any of those made a difference, but to no avail.
The best step would be to debug from source, but I don't have the time to get familiar with the codebase. I did start looking a bit ago and got to the point of trying out different wgpu surface capabilities, but I ran out of time to go further.
There's also the possibility that implementing max_fps via config on wayland might help. I get the feeling that there might be an issue with what hyprland returns for that when queried on nVidia. @wez thoughts?
EDIT: Oh, and I did run wezterm with tracing enabled, but it didn't dump any messages for rendering when the input/rendering lag would occur. If there's another log prefix that might be relevant, I can try again.
nvidia+linux has always been a bad combo. I get tired of it and switched to AMD on my linux machine, and have never looked back.
nvidia+wayland has also traditionally been a worse combo. If this issue seems specific to nvidia, I doubt there's much of anything that wezterm could do differently to make it work better; it's not like wezterm has logic that says "oooh, nvidia, let's make it suck!". It just asks for an SRGB graphics surface and sends triangles to it.
My personal position on wayland is that it is still immature compared to X11, even on AMD hardware. I run X11 because I don't have time to put up with it. I understand that wayland is the future, it just isn't the present, for me.
There are numerous open wayland related issues filed here against wezterm. Some number of them may be resolved by upgrading the SCTK dependency to the latest version. Unfortunately, the underlying wayland ecosystem crates dramatically changed their APIs (for the better!) which will make that effort essentially a rewrite of wayland support in wezterm. That should happen, but I just can't justify spending so much of my precious downtime on something that I don't use.
I'd welcome a PR for that, or alternatively, sponsorship for carve out time for it during working hours; upgrading SCTK is something I'd classify as a medium-to-large size effort. You can get a sense of what that might cost from the One-Time sponsorship section of https://github.com/sponsors/wez?frequency=one-time
It's possible that that effort doesn't resolve this issue, and would then need additional effort, and hardware to tackle and resolve.
In the meantime, what I recommend, if you're dead-set on using a wayland compositor, is using XWayland by setting enable_wayland=false in your wezterm configuration.
nvidia+linux has always been a bad combo. I get tired of it and switched to AMD on my linux machine, and have never looked back.
Oh believe me, I'm in the same boat. I'm getting ready to throw this card out the window and get an AMD card to get rid of this headache. Replacing the monitors + card both to make life easier.
nvidia+wayland has also traditionally been a worse combo. If this issue seems specific to nvidia, I doubt there's much of anything that wezterm could do differently to make it work better; it's not like wezterm has logic that says "oooh, nvidia, let's make it suck!". It just asks for an SRGB graphics surface and sends triangles to it.
Being an nVidia-specific issue wouldn't surprise me at all. It makes me feel dirty to have to think about implementing a work-around to accommodate that. It's probably not an issue with wezterm, didn't mean to imply that if that's what it sounded like.
My personal position on wayland is that it is still immature compared to X11, even on AMD hardware. I run X11 because I don't have time to put up with it. I understand that wayland is the future, it just isn't the present, for me.
Ah, I've been getting that vibe from Wayland. Been using Hyprland for the last few months. It was getting it up and running that was a major pain (and I'm using FreeBSD, not Linux), but once running it's been pretty good. I was apprehensive at first, but I guess I got lucky that I haven't had to deal with many Wayland issues, yet.
Unfortunately, the underlying wayland ecosystem crates dramatically changed their APIs (for the better!) which will make that effort essentially a rewrite of wayland support in wezterm.
I remember reading API breakage being an issue with Wayland. Glad to hear it was for the better, though I definitely get how that causes a bunch of code churn in downstream projects.
That should happen, but I just can't justify spending so much of my precious downtime on something that I don't use.
I'd welcome a PR for that, or alternatively, sponsorship for carve out time for it during working hours; upgrading SCTK is something I'd classify as a medium-to-large size effort. You can get a sense of what that might cost from the One-Time sponsorship section of https://github.com/sponsors/wez?frequency=one-time
I don't blame you at all, especially if it's that much refactoring. Based on the amount of effort required compared to the few users I'm guessing, it's not worth it (at least not now). I actually noticed the sponsorship page recently and put an item on my task list to budget some money when available. Not for this issue, but because I really like this project. I'll get around to it hopefully before end-of-year. My time is pretty tight as well.
In the meantime, what I recommend, if you're dead-set on using a wayland compositor, is using XWayland by setting enable_wayland=false in your wezterm configuration.
Going back to X11/Awesome would be a downgrade for me personally in terms of workflow. I'm just going to get an AMD card and see how that goes. I didn't think of disabling Wayland, but I'll give that a shot too.
Thanks and keep up the amazing work! Looking forward to getting into the code further down the line and hopefully submitting some PRs.
@wez agreed. I can't imagine having to deal with it as a developer. Thanks so much for your work on the project!
And @xorander00 regarding wez's comment about using XWayland that would not require you to revert from Hyprland as XWayland is a protocol for running X apps inside Wayland... it's just telling WezTerm to use that instead of native Wayland protocol.
I messed with several things today... first I updated my system and programs with nix flake update. I have two monitors: one is smaller than the other so I scale it by 1.125 in Hyprland to make it match the other. On my unscaled monitor, wezterm is performing as usual right now, and I'm pretty sure that before, I was having these hangs regardless of which monitor it was on... now, I do still have some serious sluggishness on the scaled monitor, but it kind of feels different... more like a poor framerate than the full hangs I was having before. However, reverting that monitor to a scale of 1 yields no issues! @nghiaxsm @topaxi @xorander00 @jelmore1674 are any of you using scaled monitors in Hyprland and have you experienced any improvements on newest versions of software?
@carschandler I have my scale set to 1. However, I have my resolution to 1440p instead of 4k. Because, 4k is a little small for me. I did try out wez's suggestions of just disabling wayland, and since then everything has been great for me!
For me @wez's suggestion of disabling Wayland is not an option because if I disable it I loose the ability to copy/paste from/to WezTerm and any other app.
With Wayland enabled all works fine except that WezTerm freezes until I trigger some keybinding. For example I rapidly trigger CTRL+SHIFT+L 2-5 times and WezTerm finally spawn the Debug Overlay then I close it with CTRL+D and can continue work, at least until next freeze, that will happen some seconds later ☹️
System/Version info
OS: Arch Linux x86_64
Host: 81LK (IdeaPad L340-15IRH Gaming)
Kernel: Linux 6.9.1-arch1-2
Display (HP Z27i): 2560x1440 @ 60Hz [External]
Display (CMN15E7): 1920x1080 @ 60Hz [Built-in]
WM: Hyprland (Wayland)
Terminal: WezTerm 20240520-135708-b8f94c47
CPU: Intel(R) Core(TM) i7-9750HF (12) @ 4,50 GHz
GPU: NVIDIA GeForce GTX 1650 Mobile / Max-Q [Discrete]
Memory: 3,26 GiB / 15,53 GiB (21%)
Packages list
paru -Qs "wezterm|nvidia"
local/cuda 12.5.0-1
NVIDIA's GPU programming toolkit
local/egl-wayland-git 1.1.13.r7.g067e43d-1
EGLStream-based Wayland external platform (git version)
local/libva-nvidia-driver-git 0.0.12.r11.gf3205bd-1
VA-API implementation that uses NVDEC as a backend (git version)
local/libvdpau 1.5-2
Nvidia VDPAU library
local/nvenc 7.53-2
NVIDIA Video Codec based command line encoder
local/nvidia-open-beta 555.42.02-1
NVIDIA open GPU kernel modules (beta version)
local/nvidia-prime 1.0-4
NVIDIA Prime Render Offload configuration and utilities
local/nvidia-settings-beta 555.42.02-1
Tool for configuring the NVIDIA graphics driver (beta version)
local/nvidia-utils-beta 555.42.02-1
NVIDIA drivers utilities (beta version)
local/opencl-nvidia-beta 555.42.02-1
OpenCL implemention for NVIDIA (beta version)
local/wezterm-git 20240520.135708.b8f94c47-1
A terminal emulator implemented in Rust, using OpenGL ES 2 for rendering.
wezterm.gui.enumerate_gpus()
[
{
"backend": "Vulkan",
"device": 8081,
"device_type": "DiscreteGpu",
"driver": "NVIDIA",
"driver_info": "555.42.02",
"name": "NVIDIA GeForce GTX 1650",
"vendor": 4318,
},
{
"backend": "Gl",
"device": 0,
"device_type": "Other",
"name": "NVIDIA GeForce GTX 1650/PCIe/SSE2",
"vendor": 4318,
},
]
Wezterm config
local config = {}
if wezterm.config_builder then
config = wezterm.config_builder()
end
local fonts = {
...
}
local emoji_fonts = {
...
}
for _, gpu in ipairs(wezterm.gui.enumerate_gpus()) do
if gpu.backend == "Vulkan" and (gpu.device_type == "IntegratedGpu" or gpu.device_type == "DiscreteGpu") then
config.webgpu_preferred_adapter = gpu
config.front_end = "WebGpu" -- WebGpu | OpenGL | Software
break
end
end
config = {
enable_wayland = true,
warn_about_missing_glyphs = true,
font = wezterm.font_with_fallback({
fonts[2],
emoji_fonts[1],
emoji_fonts[2],
}),
freetype_load_flags = "FORCE_AUTOHINT",
font_size = 12,
use_fancy_tab_bar = false,
window_decorations = "NONE",
hide_tab_bar_if_only_one_tab = true,
window_background_opacity = 0.75,
default_cursor_style = "BlinkingBar",
window_padding = { left = 5, right = 5, top = 5, bottom = 5 },
color_scheme = "Dark Pastel",
set_environment_variables = {
PATH = wezterm.home_dir .. ":/home/user/.local/bin/:" .. "/home/user/.cargo/bin/:" .. os.getenv("PATH"),
},
}
return config
With plasma 6.1 and the new nvidia 555.58 driver now in the archlinux repo, i decided to give wayland a shot since it solves a lot of my cut and paste issues between vm's. However wezterm is an awful experience until enabling enable_wayland = false as @wez mentions, but then i'm back to my cut and paste issues :frowning_face: . Kitty terminal seems to work perfectly fine and have no issues but i :heart: wezterm. Would it be possible @wez to relook at this issue now with new plasma and drivers finally supposed to be correcting nvidia issues for linux users ?
This might help someone.
Prerequisite: Nvidia Drivers are configured and its kernel modules are loaded.
Setup
- Gnome
- Wayland
- Nvidia
- Fedora
The wezterm response was extremely slow. While Alacritty was working as expected.
I configured the following in /etc/environment. Now wezterm's response is near alacritty. It seems the response is same as the response on X11.
GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia
EDIT: In this setup wezterm doesn't start at all when enable_wayland = false regardless wayland or x11.
This might help someone.
Prerequisite: Nvidia Drivers are configured and its kernel modules are loaded.
Setup
* Gnome * Wayland * Nvidia * FedoraThe wezterm response was extremely slow. While Alacritty was working as expected.
I configured the following in
/etc/environment. Now wezterm's response is near alacritty. It seems the response is same as the response on X11.GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidia
It doesn't work on
- KDE
- Wayland
- Nvidia
- Archlinux
This might help someone. Prerequisite: Nvidia Drivers are configured and its kernel modules are loaded. Setup
* Gnome * Wayland * Nvidia * FedoraThe wezterm response was extremely slow. While Alacritty was working as expected. I configured the following in
/etc/environment. Now wezterm's response is near alacritty. It seems the response is same as the response on X11.GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidiaIt doesn't work on
* KDE * Wayland * Nvidia * Archlinux
For this setup, you may try adding nvidia.NVreg_EnableGpuFirmware=0 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, it gives overall smoother experience with Plasma.
This might help someone.
Prerequisite: Nvidia Drivers are configured and its kernel modules are loaded.
Setup
* Gnome * Wayland * Nvidia * FedoraThe wezterm response was extremely slow. While Alacritty was working as expected.
I configured the following in
/etc/environment. Now wezterm's response is near alacritty. It seems the response is same as the response on X11.GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidia
Got running message loop: Error while flushing display: Broken pipe (os error 32).
I think it's better to wait for Wez to fix it ......
This might help someone. Prerequisite: Nvidia Drivers are configured and its kernel modules are loaded. Setup
* Gnome * Wayland * Nvidia * FedoraThe wezterm response was extremely slow. While Alacritty was working as expected. I configured the following in
/etc/environment. Now wezterm's response is near alacritty. It seems the response is same as the response on X11.GBM_BACKEND=nvidia-drm __GLX_VENDOR_LIBRARY_NAME=nvidiaGot
running message loop: Error while flushing display: Broken pipe (os error 32).I think it's better to wait for Wez to fix it ......
Yep.
Today I noticed some issues with that configuration, other apps slowing down, for example Firefox.
Wezterm (20240812-215703-30345b36) works fluently on my system now:
- KDE
- Wayland
- Nvidia
- Archlinux
Hi, the issue is still present on my system with wezterm 20240203-110809-5046fc22.
The config.enable-wayland = false fix also still works.
- Cosmic
- Wayland
- Nvidia (GTX 1660 Super)
- Archlinux
On arch, wezterm is still pretty outdated (from beginning of February), I assume due to it not having an official release since then.
Try the aur/wezterm-git package or use the appimage from the nightly release section here.
@topaxi Thank you very much, I will use the aur/wezterm-git package from now on.
However, the issue did not disappear for me with wezterm 20240928-215536-a2f2c07a. :(
Using XWayland is a nice workaround for now.
I'm living this issue right now but it wasn't happening before. I just need to disable explicit sync for my Hyprland by saying render:explicit_sync = false in my config then it slowed Wezterm.
