wezterm
wezterm copied to clipboard
wez
Long delay updating GUI, periodic key repeats
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
KDE/sddm
WezTerm version
20240609_095134_f5e496eb-1.fedora40
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
Using the latest stable and latest nightly builds, from Flatpak (stable only), AppImage, and RPM sources, WezTerm has long delays updating the GUI. It shows as delays accepting keystrokes, but no matter how long I wait for it I can always make it immediately refresh by pressing a modifier (Ctrl, Alt). Whatever I typed, sometimes including repeated keys that shouldn't be there, appears as soon as a modifier is pressed. The delay isn't consistent, sometimes it's fractions of a second but sometimes it's tens of seconds (possibly longer but that's about where I get impatient).
Using WEZTERM_LOG=debug, the log doesn't even update until WezTerm itself repaints, so it's like WezTerm isn't even receiving the key input, or receives it but isn't processing or registering it. Nothing shows up in journalctl output.
To Reproduce
Run WezTerm and type.
Configuration
None, reproduces with no config and with --skip-config
Expected Behavior
No delays
Logs
Too long, see attached file.
Anything else?
This did not happen when using GNOME/gdm with Wayland on Fedora 40, it started as soon as I switched to KDE/sddm. No other apps are showing this behaviour so far, either delays or unexpected key repeats.
I can't switch renderers either. If I run with --config front_end=WebGpu or --config front_end=Software WezTerm fails to start with an error that the value I passed was evaluated as nil.
18:25:43.868 DEBUG config::config > Apply use_ime=false to config
18:25:43.869 DEBUG config::config > Apply debug_key_events=true to config
18:25:43.869 DEBUG config::config > Apply front_end=WebGpu to config
18:25:43.870 ERROR wezterm_gui > common_init: set_config_overrides: apply_overrides_to: runtime error: [string "--config front_end=WebGpu"]:5: WebGpu evaluated as nil. Check for missing quotes or other syntax issues
stack traceback:
[C]: in ?
[C]: in function 'error'
[string "--config front_end=WebGpu"]:5: in main chunk; terminating
@jgoguen Are you on the latest Plasma 6.1 beta or another kind of plasma 6.1 pre-release?
I'm having the same problem with Plasma 6.1 with wayland, I think it has to do with the new explicit-sync wayland protocol that ships in Plasma 6.1.
If you have a graphics driver that supports wayland drm-syncobj-v1 (all the flagship mesa drivers now), and a wayland compositor that supports drm-syncobj-v1 (eg, plasma 6.1), then the wayland graphics stack uses "explicit sync" refreshes instead of "implicit sync", that means the client application can take advantage of triple buffering, variable refresh rates, and other fancy features. However since upgrading I've seen lots of issues just like this one where applications stop updating for seconds or more.
With wezterm, I've found a (awful) workaround, if you continually move your mouse around the terminal window while entering input, then the renderer continues to refresh and the lag disappears.
You would think launching with wayland would fix it:
env -u WAYLAND_DISPLAY wezterm
However in this case it runs in XWayland mode, but latest versions of XWayland released since May also use explicit-sync (it was added in XWayland even before KWin got it), so we see the same problem.
Update to this:
I remembered I had added config.enable_wayland = false to my wezterm configuration a couple moths ago due to some wayland rendering glitches I was seeing. So I was always running in XWayland mode when running wezterm.
On a whim, I just changed to config.enable_wayland = true and behold the update delays, freezes, and missing frames are gone, its rendering just fine in with real wayland mode.
So I suppose this is a problem with XWayland.
I'm not on any beta, I'm using the latest available with Fedora 40 (currently 6.0.5). My driver does support explicit sync though. But enable_wayland=true is the default setting, and I can verify in the debug overlay that it's set to true.
> print(window:effective_config().ena
19:28:02.491 INFO logging > lua: true
I'm not waving my mouse around to get a terminal to update. The whole point to me of using the terminal more is needing the mouse less. :sweat_smile: But, it does work for me as well. Doesn't help the unexpected key repeats
I got the bright idea to set front_end="WebGpu" in my config file... and that blew up spectacularly, but with some new error details:
% RUST_BACKTRACE=full wezterm
DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.
wp_linux_drm_syncobj_surface_v1@81: error 4: explicit sync is used, but no acquire point is set
19:38:06.777 ERROR wgpu_hal::vulkan::adapter > get_physical_device_surface_present_modes: ERROR_SURFACE_LOST_KHR
19:38:06.777 ERROR wgpu_hal::vulkan::adapter > get_physical_device_surface_formats: ERROR_SURFACE_LOST_KHR
19:38:06.790 ERROR env_bootstrap > panic at /__w/wezterm/wezterm/vendor/wgpu-0.18.0/src/backend/direct.rs:778:18 - !?
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: <unknown>
14: <unknown>
15: <unknown>
16: <unknown>
17: <unknown>
18: <unknown>
19: <unknown>
20: <unknown>
21: <unknown>
22: <unknown>
23: <unknown>
24: <unknown>
25: __libc_start_call_main
26: __libc_start_main_impl
27: <unknown>
thread 'main' panicked at /__w/wezterm/wezterm/vendor/wgpu-0.18.0/src/backend/direct.rs:778:18:
Error in Surface::configure: Validation Error
Caused by:
Requested format Rgba8UnormSrgb is not in list of supported formats: []
stack backtrace:
0: 0x55bc64356cfc - <unknown>
1: 0x55bc6438a370 - <unknown>
2: 0x55bc6435187f - <unknown>
3: 0x55bc64356ae4 - <unknown>
4: 0x55bc64358827 - <unknown>
5: 0x55bc6435858f - <unknown>
6: 0x55bc62861d83 - <unknown>
7: 0x55bc64358e38 - <unknown>
8: 0x55bc64358b8e - <unknown>
9: 0x55bc643571c6 - <unknown>
10: 0x55bc643588f2 - <unknown>
11: 0x55bc62440f95 - <unknown>
12: 0x55bc62b92c8e - <unknown>
13: 0x55bc62b963db - <unknown>
14: 0x55bc62ba4453 - <unknown>
15: 0x55bc62ad5131 - <unknown>
16: 0x55bc628319e1 - <unknown>
17: 0x55bc62774200 - <unknown>
18: 0x55bc6283ac79 - <unknown>
19: 0x55bc633dc328 - <unknown>
20: 0x55bc63368075 - <unknown>
21: 0x55bc63560e19 - <unknown>
22: 0x55bc63546308 - <unknown>
23: 0x55bc63447825 - <unknown>
24: 0x55bc6343d0b9 - <unknown>
25: 0x55bc627b5b49 - <unknown>
26: 0x55bc627b7307 - <unknown>
27: 0x55bc62553db3 - <unknown>
28: 0x55bc626c16b9 - <unknown>
29: 0x55bc643480e7 - <unknown>
30: 0x55bc626c16ae - <unknown>
31: 0x7f1051954088 - __libc_start_call_main
32: 0x7f105195414b - __libc_start_main_impl
33: 0x55bc624417de - <unknown>
34: 0x0 - <unknown>
thread panicked while processing panic. aborting.
zsh: IOT instruction (core dumped) RUST_BACKTRACE=full wezterm
Is there any updates to this? I am experiencing this issue with sway. Likely an explicit sync issue as I have had other (mostly crashing) problems with select applications after explicit sync landed this year.
