Wezterm rendering is broken in master

[pshirshov]

❯  nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.10.6, NixOS, 24.11 (Vicuna), 24.11.20240819.18c70e9`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.5`
 - channels(root): `"nixos"`
 - nixpkgs: `/nix/store/cb28mf5ha3929l7y9vlwswaz40r9b1yn-source`

[liketechnik]

• Upstream issue: textures broken on NixOS master branch wez/wezterm#5990
• Workaround 1: config.front_end="WebGpu" (from textures broken on NixOS master branch wez/wezterm#5990 (comment); originally mentioned in Build failure: wezterm #334650 (comment))
• Workaround 2: use the wezterm from the 24.05 branch (see the linked upstream issues for help)

[pshirshov]

Seems like the workaround doesn't work for me:

❯ wezterm
wp_linux_drm_syncobj_surface_v1#65: error 4: explicit sync is used, but no acquire point is set
17:09:59.440  ERROR  wezterm_gui > running message loop: error during event_q.dispatch protocol_error=Some(ProtocolError { code: 4, object_id: 65, object_interface: "wp_linux_drm_syncobj_surface_v1", message: "" }): Protocol error (os error 71); terminating
warning: queue 0x55f988a471c0 destroyed while proxies still attached:

[SuperSandro2000]

Try disabling Wayland and fallback to xwayland.

I tried the latest version from master and that didn't fix this bug.

[zierf]

@pshirshov Setting the frontend to WebGpu also causes my WezTerm to crash.

The workaround is to set the following in the ~/.wezterm.lua configuration.

front_end = "WebGpu",
enable_wayland = false,

Frontend WebGpu without disabling Wayland crashes even in my pinned version. I guess OpenGL was still the standard back then and it didn't have the above bug with font rendering.

[zierf]

I posted a temporary workaround using WezTerm as Flake in WezTerm Issue #5990. Then it doesn't matter if front_end is not set, OpenGL or has been switched to WebGpu.

Credits go to davidsierradz for figuring this out. I just described it in a little more detail.

[knl]

I have the same issue on aarch64-darwin, where no wayland is used.

However, enabling front_end = "WebGpu" fixes the issue.

[SuperSandro2000]

For me this issue got fixed on nixos-unstable without any changes to Wezterm. Maybe a mesa/driver update?

[matthiasdotsh]

For me this issue got fixed on nixos-unstable without any changes to Wezterm. Maybe a mesa/driver update?

For me wezterm is still broken using nixos-unstable (1355a0c).

[SuperSandro2000]

Is hardware acceleration working for you in other applications? If not that is the issue.

[dpc]

I can play TF2 and other 3d games just fine, wezterm rendering still just squares, just tried current nixos-unstable.

[pshirshov]

For me the rendering is still broken w/o webgpu and wezterm just crashes w/wegbpu

[eeedean]

For me on macOS it's broken like seen with OpenGL- or Software-Frontend but works with WebGpu.

Cannot get it to correctly display on my NixOS VirtualBox VM (x86_64-linux) with 3D accelleration activated and VMSVGA Graphics Controller.
Wont start with WebGpu und is rendering broken with OpenGL or Software.

It seems to be broken since Rust 1.80 upgrade:

• using a58bc8a, it does work (still Rust 1.79)
• with c3aa7b8 it broke (due to 1.80 upgrade)
• after e572285 it builds again, but the display is broken

I took the two upper commits from Hydra and the last one is of course your fix-merge-commit, @SuperSandro2000.

Either something related broke inbetween or it is actually something around the Rust 1.80-Migration. Unfortunately however, I have no clue about Rust. 🐱

Thanks for your efforts, maintaining the package!

[nezia1]

For me the rendering is still broken w/o webgpu and wezterm just crashes w/wegbpu

Do you have a Nvidia GPU? If so, Wezterm is currently broken with Nvidia using WebGL, which is really bad for us NixOS users as long as rendering is still broken with OpenGL... See wez/wezterm#6050

[pshirshov]

Nope, AMD.

[ilaumjd]

I don't use NixOS, it is also broken on Darwin and my AMD Fedora machine using WebGL.

[samuela]

FWIW still an issue on macOS as of 34a6264.

[futile]

It seems like wezterm has recently started planning for a release, so we might soon see a change here: wez/wezterm#6341

(Leave a 🚀 or ❤️ to support! As usual, if you want to comment/join, please read the full discussion, especially the posts by the project owner, wez ❤️ )