wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
17.73k stars 793 forks source link

poll_for_queued_event: X(Match(RequestError when front_end="WebGpu" #4290

Open rocket-matt opened 1 year ago

rocket-matt commented 1 year ago

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:

ERROR  wezterm_gui > running message loop: process_queued_xcb: poll_for_queued_event: X(Match(RequestError { response_type: 0, error_code: 8, sequence: 286, bad_value: 102760457, minor_opcode: 4, major_opcode: 149, pad: 1 }), None); terminating

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

daniel-vainsencher commented 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
wez commented 9 months ago

@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!

Janno commented 9 months ago

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.

wez commented 9 months ago

Try using the opengl front end; see https://github.com/wez/wezterm/issues/3904#issuecomment-1819571416

Janno commented 9 months ago

That did the trick for me. Thanks!

daniel-vainsencher commented 9 months ago

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.

wez commented 9 months ago

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!)

wez commented 9 months ago

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.