Open rocket-matt opened 1 year ago
I am seeing the same (details below), also on pop_os, with no config (reproduced using -n
). I have recently upgraded pop_os packages, which suggests some dependency changed in a way that broke wezterm :/
Happy to collaborate on finding a fix/workaround, but not familiar with the codebase. I dabble in Rust so tried the rust_backtrace=1 thing, but the error seems to be too well controlled for that to add any information... ;)
(base) danielv@pop-os:~/Software/wezterm$ uname -a
Linux pop-os 6.4.6-76060406-generic #202307241739~1695312586~22.04~4d8f3e9 SMP PREEMPT_DYNAMIC Thu S x86_64 x86_64 x86_64 GNU/Linux
(base) danielv@pop-os:~/Software/wezterm$ git checkout main
M deps/freetype/freetype2
M deps/harfbuzz/harfbuzz
Previous HEAD position was f4abf8fde front_end defaults to OpenGL again
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
(base) danielv@pop-os:~/Software/wezterm$ git submodule update --init --recursive
Submodule path 'deps/freetype/freetype2': checked out 'e4586d960f339cf75e2e0b34aee30a0ed8353c0d'
Submodule path 'deps/freetype/freetype2/subprojects/dlg': checked out '72dfcc858c040c54a6a0b88fcb7e70ee186d3167'
Submodule path 'deps/harfbuzz/harfbuzz': checked out '0967a3e24ab5d79cc55dbe224652d8aabd942def'
(base) danielv@pop-os:~/Software/wezterm$ cargo run --release --bin wezterm
Compiling wezterm-input-types v0.1.0 (/home/danielv/Software/wezterm/wezterm-input-types)
...
Compiling wezterm v0.1.0 (/home/danielv/Software/wezterm/wezterm)
Finished release [optimized] target(s) in 19.83s
Running `target/release/wezterm`
10:44:23.745 ERROR wezterm_gui > running message loop: process_queued_xcb: poll_for_queued_event: X(Match(RequestError { response_type: 0, error_code: 8, sequence: 287, bad_value: 56623113, minor_opcode: 4, major_opcode: 149, pad: 1 }), None); terminating
@rocket-matt this error:
15:14:00.736 ERROR wezterm > failed to exec "/home/matt/.cargo/bin/wezterm-gui": Os { code: 2, kind: NotFound, message: "No such file or directory" }; terminating
suggests that you have not installed wezterm-gui
.
Note that using cargo install
to install wezterm is not supported as it has no way to ensure that all the right pieces land in the right places.
I'd suggest looking carefully at https://github.com/wez/wezterm/blob/main/README-DISTRO-MAINTAINER.md if you are going to install directly from source for yourself.
I would recommend using one of the pre-built packages to save yourself some headaches!
I am getting a very similar error message after installing wezterm using this deb image:
https://github.com/wez/wezterm/releases/download/nightly/wezterm-nightly.Debian12.deb (md5 3844c13f3a029337026a22e1fc44f340
)
14:31:57.041 ERROR wezterm_gui > running message loop: process_queued_xcb: poll_for_queued_event: X(Match(RequestError { response_type: 0, error_code: 8, sequence: 271, bad_value: 113246217, minor_opcode: 4, major_opcode: 149, pad: 1 }), None); terminating
wezterm-gui
exists but fails with the same error message.
Try using the opengl front end; see https://github.com/wez/wezterm/issues/3904#issuecomment-1819571416
That did the trick for me. Thanks!
I would say that 90% of the pain here can be removed by logging something like "Failure in WebGPU backend, try a different one.", in case that is easier than resolving the underlying issue with webgpu.
The fact that there are multiple issues for the same underlying problem seems also a symptom of the confusion.
The challenge with that is: how do you know from that error message that this is a webgpu problem? It's not obviously connected to the webgpu logic; the window
crate where we process xcb has no idea that webgpu even exists. I think the reality is that this is probably a bug in the rust xcb bindings that is exacerbated by something that the nvidia vulkan driver is doing (or not doing!)
re: multiple issues, the problem there is that most people are (phrasing this charitably!) too busy to search to find the matching issue. I'm dramatically outnumbered by users and don't have as much time as I would like to triage and dedup.
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
Running Pop_OS!
No LSB modules are available. Distributor ID: Pop Description: Pop!_OS 22.04 LTS Release: 22.04 Codename: jammy
Linux pop-os 6.4.6-76060406-generic #202307241739~1692717645~22.04~5597803 SMP PREEMPT_DYNAMIC Tue A x86_64 x86_64 x86_64 GNU/Linux
WezTerm version
20230911-075810-70931f58
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
This error occurs on start up:
It was built from latest source in github following instructions (include get-deps, submodules etc).
This is after wezterm was working perfectly on my system before (albeit an older version).
To Reproduce
Just start it either via
cargo run
or calling it directly.Configuration
local wezterm = require("wezterm") local config = { window_frame = { -- The font used in the tab bar. font = wezterm.font({ family = "DejaVuSansMono" }), font_size = 12.0, }, hide_tab_bar_if_only_one_tab = true, font = wezterm.font("DejaVuSansMono Nerd Font"), font_size = 11.0, window_background_opacity = 0.9, initial_rows = 50, initial_cols = 120, }
config.keys = { { key = "/", mods = "SUPER|ALT", action = wezterm.action.SplitHorizontal({ domain = "CurrentPaneDomain" }), }, { key = "#", mods = "SUPER|ALT", action = wezterm.action.SplitVertical({ domain = "CurrentPaneDomain" }), }, }
return config
Expected Behavior
I expect wezterm to work as usual.
Logs
15:14:00.736 ERROR wezterm > failed to exec "/home/matt/.cargo/bin/wezterm-gui": Os { code: 2, kind: NotFound, message: "No such file or directory" }; terminating
Anything else?
No response