textures broken on NixOS master branch

[crabdancing]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

kwin 6.1.4 (NixOS)

WezTerm version

wezterm 20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

Wezterm no longer displays meaningful characters. All characters are rendered as blocks.

To Reproduce

• Open Wezterm (am on NixOS master branch)
• Fails to display characters

Configuration

-- Generated by Home Manager.
-- See https://wezfurlong.org/wezterm/

local wezterm = require 'wezterm';

-- Add config folder to watchlist for config reloads.
local wezterm = require 'wezterm';
wezterm.add_to_config_reload_watch_list(wezterm.config_dir)

local config = {}
local act = wezterm.action

config.keys = {
  {
    key = '!',
    mods = 'SHIFT | ALT',
    action = wezterm.action_callback(function(win, pane)
      local _tab, _window = pane:move_to_new_window()
    end),
  },
  { key = 'LeftArrow', mods = 'CTRL|SHIFT', action = act.ActivateTabRelative(-1) },
  { key = 'RightArrow', mods = 'CTRL|SHIFT', action = act.ActivateTabRelative(1) },
  {
    key = 'q',
    mods = 'ALT',
    action = wezterm.action.CloseCurrentPane { confirm = true },
  },
  {
    key = 't', mods = 'CTRL|SHIFT',
    action = act.SpawnTab 'CurrentPaneDomain',
  },
  { key = 'y',  mods = 'ALT',
    action = act.SpawnCommandInNewTab {
      args = { 'htop' },
    },
  },
  { key = 'UpArrow', mods = 'SHIFT', action = act.ScrollByLine(-1) },
  { key = 'DownArrow', mods = 'SHIFT', action = act.ScrollByLine(1) },
  { key = 'v', mods = 'CTRL', action = act.PasteFrom("Clipboard") },
  { key = 'q', mods = 'CTRL', action = act.Multiple { act.ScrollToBottom, act.SendKey { key = 'q', mods = 'CTRL' } } },
  { key = 'd', mods = 'CTRL', action = act.Multiple { act.ScrollToBottom, act.SendKey { key = 'd', mods = 'CTRL' } } },
  { key = 'Escape', action = act.Multiple { act.ScrollToBottom, act.SendKey { key = 'Escape' } } },
  { key = 'Enter', action = act.Multiple { act.ScrollToBottom, act.SendKey { key = 'Enter' } } },
    -- Pane zoom
  { key = ';',          mods = 'CTRL',       action = act.TogglePaneZoomState },
  -- Pane resize
  { key = 'LeftArrow',  mods = 'ALT|SHIFT',  action = act.AdjustPaneSize { 'Left', 1 } },
  { key = 'RightArrow', mods = 'ALT|SHIFT',  action = act.AdjustPaneSize { 'Right', 1 } },
  { key = 'UpArrow',    mods = 'ALT|SHIFT',  action = act.AdjustPaneSize { 'Up', 1 } },
  { key = 'DownArrow',  mods = 'ALT|SHIFT',  action = act.AdjustPaneSize { 'Down', 1 } },
  {
    key = 'a',
    mods = 'SHIFT|ALT',
    action = wezterm.action.SplitPane {
      direction = 'Left',
      size = { Percent = 50 },
    },
  },
  {
      key = 'd',
      mods = 'SHIFT|ALT',
      action = wezterm.action.SplitPane {
        direction = 'Right',
        size = { Percent = 50 },
    },
  },
  {
      key = 'w',
      mods = 'SHIFT|ALT',
      action = wezterm.action.SplitPane {
        direction = 'Up',
        size = { Percent = 50 },
    },
  },
  {
      key = 's',
      mods = 'SHIFT|ALT',
      action = wezterm.action.SplitPane {
        direction = 'Down',
        size = { Percent = 50 },
    },
  },

  {
    key = 'c',
    mods = 'CTRL',
    action = wezterm.action_callback(function(window, pane)
      local has_selection = window:get_selection_text_for_pane(pane) ~= ''
      if has_selection then
        window:perform_action(act.CopyTo 'ClipboardAndPrimarySelection', pane)

        window:perform_action(act.ClearSelection, pane)
      else
        window:perform_action(act.SendKey { key = 'c', mods = 'CTRL' }, pane)
      end
    end),
  }

}

config.mouse_bindings = {

  {
    event = { Up = { streak = 1, button = "Left" } },
    mods = "NONE",
    action = wezterm.action { ExtendSelectionToMouseCursor = "Cell" }
  },

  -- and make CTRL-Click open hyperlinks
  {
    event = { Up = { streak = 1, button = 'Left' } },
    mods = 'CTRL',
    action = act.OpenLinkAtMouseCursor,
  },
  -- NOTE that binding only the 'Up' event can give unexpected behaviors.
  -- Read more below on the gotcha of binding an 'Up' event only.
}
for i = 1, 8 do
  -- ALT + number to activate that tab
  table.insert(config.keys, {
    key = tostring(i),
    mods = 'ALT',
    action = act.ActivateTab(i - 1),
  })
end


config.initial_rows = 28
config.initial_cols = 132
-- I think it erroneously hides mouse cursor sometimes, so let's disable that
config.hide_mouse_cursor_when_typing = false
config.enable_scroll_bar = true

-- This is bad UX for using Ctrl+C for copy
config.scroll_to_bottom_on_input = false


-- Return will be inserted at the very end of the config, generated through Nix
-- return config

config.font_size = 10
config.enable_wayland = false
config.warn_about_missing_glyphs = false
return config

Expected Behavior

Expected to display meaningful characters, not blocks

Logs

N/A

Anything else?

Methodology & notes

• After clearing logs from /run/user/1000/wezterm, and then re-closing and re-opening wezterm, there are still no logs in the directory -- just socket files & X11 symlink.
• Have tried clearing entire config, and running wezterm stock. This did not work either.
• No other programs seem to be behaving abnormally on this iteration of my NixOS system. Only Wezterm.
• Wezterm is not printing any errors or warnings via STDOUT/STDERR when it is started.

Since wezterm ls-fonts might be relevant, here you go:

Primary font:
wezterm.font_with_fallback({
  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf index=0 variation=3, FontConfig
  {family="Fira Code", weight="Medium"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})


When Intensity=Half Italic=true:
wezterm.font_with_fallback({
  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf, FontConfig
  -- Will synthesize italics
  {family="Fira Code", weight="Light"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})


When Intensity=Half Italic=false:
wezterm.font_with_fallback({
  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf, FontConfig
  {family="Fira Code", weight="Light"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})


When Intensity=Bold Italic=false:
wezterm.font_with_fallback({
  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf index=0 variation=4, FontConfig
  {family="Fira Code", weight="DemiBold"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})


When Intensity=Bold Italic=true:
wezterm.font_with_fallback({
  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf index=0 variation=4, FontConfig
  -- Will synthesize italics
  {family="Fira Code", weight="DemiBold"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})


When Intensity=Normal Italic=true:
wezterm.font_with_fallback({
  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf index=0 variation=3, FontConfig
  -- Will synthesize italics
  {family="Fira Code", weight="Medium"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})

Title font:
wezterm.font_with_fallback({
  -- <built-in>, BuiltIn
  {family="Roboto", weight="Bold"},

  -- /home/ada/.local/share/fonts/FiraCode-VF.ttf index=0 variation=3, FontConfig
  {family="Fira Code", weight="Medium"},

  -- <built-in>, BuiltIn
  "JetBrains Mono",

  -- /nix/store/3q1szld5xjkyxqsy5cn37jqz8jvbm1mn-noto-fonts-color-emoji-2.042/share/fonts/noto/NotoColorEmoji.ttf, FontConfig
  -- Assumed to have Emoji Presentation
  -- Pixel sizes: [128]
  "Noto Color Emoji",

  -- /home/ada/.local/share/fonts/SymbolsNerdFontMono-Regular.ttf, FontConfig
  "Symbols Nerd Font Mono",

})

Screenshots

After typing some random commands:

Emoji picker:

Versioning constraints

Did not try nightly because Wezterm does not have a Nix flake, and thus, is difficult to run nightly without writing a custom overlay. I have however tried building & running the version shipped by nixpkgs master (nix run 'nixpkgs/master#wezterm') to the same effect. Earlier versions do not seem to work, though:

> nix run 'nixpkgs/nixos-24.05#wezterm'
16:02:13.990  ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

[davidsierradz]

Did not try nightly because Wezterm does not have a Nix flake

Try nix run 'github:wez/wezterm/main?dir=nix'

[crabdancing]

@davidsierradz

Oh, cool! I had no idea that was added. Unfortunately, it gives me about the same effect as trying other versions from nixpkgs branches:

nix run 'github:wez/wezterm/main?dir=nix'
23:42:34.984  ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

Incidentally, I found this issue also mentioned by the folks over at nixpkgs.

SuperSandro2000's workaorund of config.front_end = "WebGpu" worked great for me, which I'm thrilled about (I've been slowly chugging along with Konsole all day and suffering for it).

But since the underlying problem is still there, I'll keep this issue open to track it.

[jjpe]

@crabdancing What I'm doing in the meantime is nix run github:NixOS/nixpkgs/nixos-24.05#wezterm.
That version still works properly as of now from what I can see, and should continue to work since 24.05 is the current stable version.

That's general advice btw: if a regular pkg breaks on unstable, you can always try to run the one from the currently stable channel.

[crabdancing]

@jjpe

Yeah, that's not bad advice! I have quite a few packages in my environment.systemPackages of the form:

inputs.nixpkgs-stable.legacyPackages.${pkgs.system}.<package>. For some reason, nixpkgs?ref=nixos-24.05 wezterm version won't run on any of my nixpkgs?ref=master machines, though.

[davidsierradz]

23:42:34.984 ERROR wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

I fixed this error linking the wezterm' flake input the same as my primary nixpkgs:

nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
wezterm-flake.url = "github:wez/wezterm/main?dir=nix";
wezterm-flake.inputs.nixpkgs.follows = "nixpkgs";

[rgruyters]

sorry for the noob question, but how do I pass the wezterm-flake input to environment.systemPackages = []?

I have tried the following, but unfortunately it didn't work for me.

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
    nix-darwin = {
      url = "github:LnL7/nix-darwin";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    wezterm-flake = {
      url = "github:wez/wezterm/main?dir=nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = inputs@{ self, nix-darwin, nixpkgs, wezterm-flake }:
  {
    # Build darwin flake using:
    # $ darwin-rebuild build --flake .#system
    darwinConfigurations."system" = nix-darwin.lib.darwinSystem {
      system = "aarch64-darwin";
      specialArgs = { inherit inputs self; };
      modules = [
          ./darwin.nix
      ];
    };

    # Expose the package set, including overlays, for convenience.
    darwinPackages = self.darwinConfigurations."system".pkgs;
  };
}

And in my darwin.nix (snippet of it...)

{ self, pkgs, lib, inputs, ... }: {
  # List packages installed in system profile. To search by name, run:
  # $ nix-env -qaP | grep wget
  # These packages are available system wide
  environment.systemPackages =
    [
      pkgs.neovim
      pkgs.ripgrep
      pkgs.fzf
      pkgs.direnv
      pkgs.bat
      pkgs.starship
      pkgs.tmux
      pkgs.zoxide
      pkgs.fd
      pkgs.git
      pkgs.lazygit
      pkgs.lazydocker
      pkgs.sesh
      inputs.wezterm-flake.packages."${pkgs.system}".wezterm
    ];
}

I got the error

...
       error: attribute 'wezterm' missing

       at /nix/store/zlb5kg2yc3y6djsvscxxyx9w7bzmixm1-source/nix/darwin.nix:20:7:

           19|       pkgs.sesh
           20|       inputs.wezterm-flake.packages.${pkgs.system}.wezterm
             |       ^
           21|     ];

[crabdancing]

@rgruyters

You're pretty close!

It looks like it would be inputs.wezterm-flake.packages.${pkgs.system}.default, as the flake doesn't expose an explicit wezterm package.

Edit:

I wrote up a quick tutorial and put it here if you wanna figure out how you can find out this stuff. :3

[rgruyters]

@crabdancing this works perfectly, unfortunately I miss the Wezterm.app to start Wezterm from my Mac. Do I need to add some extra settings?
Although I saw in the default.nix for wezterm nixpkgs that it should be adding it. (if i understand correctly)

https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/terminal-emulators/wezterm/default.nix#L116-L123

[crabdancing]

@rgruyters

TBH, I haven't touched a Mac machine in over a decade, and have very little clue how they work, or how nixpkgs integrates with them. Sorry. :P I can tell you that the way you're reading the default.nix is likely correct -- it does seem to be trying to expose some sort of .app icon. The only way I could think of to work around it not showing up was making a shell script shim, but that's obviously bad. I recommend asking the Matrix, or the unofficial Discord. (The latter of which I'm looking at rn, and seems to have a #macos section). Alternatively, maybe open a bug report on upstream nixpkgs.

[yshui]

Any idea what is going on here? Presumably this is an incompatibility with a newer version of GL library?

[fr13ndxd]

nix run github:nixos/nixpkgs/nixpkgs-unstable#wezterm and nix run github:nixos/nixpkgs/nixos-unstable#wezterm works for me now (no crash and no weird fonts)

[jjpe]

@fr13ndxd That's odd.
I just (as in 2 minutes ago) tried them both on NixOS unstable, and both still result in garbled rendering for me.

I would expect those commands to yield more or less the same result for every user, so this is definitely strange.

[KucharczykL]

Neither work for me either

[fr13ndxd]

oh, it doesnt work for me anymore after a reboot...

[SuperSandro2000]

That is a pretty good indicator that it has something to do with the graphics driver loaded because they are not replaced on updates. So maybe a mesa update broke things?

[zierf]

@davidsierradz

Did not try nightly because Wezterm does not have a Nix flake

Try nix run 'github:wez/wezterm/main?dir=nix'

Loading the Flake without setting a specific frontend and not disabling wayland gives this output:

$> nix run 'github:wez/wezterm/main?dir=nix'

ERROR  env_bootstrap > panic at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88 - called `Option::unwrap()` on a `None` value
   0: env_bootstrap::register_panic_hook::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::panicking::panic
   7: core::option::unwrap_failed
   8: <wgpu_hal::gles::egl::Instance as wgpu_hal::Instance<wgpu_hal::gles::Api>>::init
   9: wgpu_core::instance::Instance::new
  10: wgpu::Instance::new
  11: wezterm_gui::termwindow::TermWindow::new_window::{{closure}}
  12: <async_task::runnable::Builder<M>::spawn_local::Checked<F> as core::future::future::Future>::poll
  13: async_task::raw::RawTask<F,T,S,M>::run
  14: window::spawn::SpawnQueue::run
  15: <window::os::x11::connection::XConnection as window::connection::ConnectionOps>::run_message_loop
  16: wezterm_gui::run_terminal_gui
  17: wezterm_gui::main
  18: std::sys_common::backtrace::__rust_begin_short_backtrace
  19: std::rt::lang_start::{{closure}}
  20: std::rt::lang_start_internal
  21: main
  22: __libc_start_call_main
  23: __libc_start_main@@GLIBC_2.34
  24: _start

thread 'main' panicked at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Using front_end = "WebGpu":

$> nix run 'github:wez/wezterm/main?dir=nix'

ERROR  env_bootstrap > panic at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88 - called `Option::unwrap()` on a `None` value
   0: env_bootstrap::register_panic_hook::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::panicking::panic
   7: core::option::unwrap_failed
   8: <wgpu_hal::gles::egl::Instance as wgpu_hal::Instance<wgpu_hal::gles::Api>>::init
   9: wgpu_core::instance::Instance::new
  10: wgpu::Instance::new
  11: wezterm_gui::termwindow::TermWindow::new_window::{{closure}}
  12: <async_task::runnable::Builder<M>::spawn_local::Checked<F> as core::future::future::Future>::poll
  13: async_task::raw::RawTask<F,T,S,M>::run
  14: window::spawn::SpawnQueue::run
  15: <window::os::wayland::connection::WaylandConnection as window::connection::ConnectionOps>::run_message_loop
  16: wezterm_gui::run_terminal_gui
  17: wezterm_gui::main
  18: std::sys_common::backtrace::__rust_begin_short_backtrace
  19: std::rt::lang_start::{{closure}}
  20: std::rt::lang_start_internal
  21: main
  22: __libc_start_call_main
  23: __libc_start_main@@GLIBC_2.34
  24: _start

thread 'main' panicked at /build/cargo-vendor-dir/wgpu-hal-0.18.1/src/gles/egl.rs:798:88:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
panicked at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/thread/local.rs:262:26:
thread panicked while processing panic. aborting.
zsh: IOT instruction (core dumped)  nix run 'github:wez/wezterm/main?dir=nix

Using front_end = "WebGpu" and enable_wayland = false:

$> nix run 'github:wez/wezterm/main?dir=nix'

ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

Just with enable_wayland = false:

$> nix run 'github:wez/wezterm/main?dir=nix'

ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed: with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory, with_egl_lib(libEGL.so.1) failed: egl GetDisplay: Failed but with error code: SUCCESS, libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

[zierf]

Oh, very interesting. As mentioned by davidsierradz it works if you include WezTerm as a flake but let it use the system's nixpks.

Then you no longer need this configuration in ~/.wezterm.lua:

  front_end = "WebGpu",
  enable_wayland = false,

It then doesn't matter whether you didn't specify front_end, explicitly set it to OpenGL or switched it to WebGpu. It also works with enable_wayland set to true and false as well as without.

System Flake:

{
  description = "Your NixOS Flake";

  inputs = {
    # Official NixOS package source, using nixos-unstable branch here
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

    # custom flakes
    wezterm = {
      url = "github:wez/wezterm/main?dir=nix";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    # …
  };

  outputs = { self, nixpkgs, ... } @inputs:
    # more configuration
}

configuration.nix:

  environment.systemPackages = with pkgs; [
    # custom remote flakes
    inputs.wezterm.packages.${pkgs.system}.default

    # official system packages
    # …
  ];

Here are the current revisions for my nixpkgs and WezTerm from the metadata of my system flake.

$> nix flake metadata

├───nixpkgs: github:NixOS/nixpkgs/8a3354191c0d7144db9756a74755672387b702ba
└───wezterm: github:wez/wezterm/30345b36d8a00fed347e4df5dadd83915a7693fb?dir=nix
    ├───flake-utils: github:numtide/flake-utils/b1d9ab70662946ef0850d488da1c9019f3a9752a
    │   └───systems: github:nix-systems/default/da67096a3b9bf56a91d16901293e51ba5b49a27e
    ├───freetype2: github:wez/freetype2/e4586d960f339cf75e2e0b34aee30a0ed8353c0d
    ├───harfbuzz: github:harfbuzz/harfbuzz/63973005bc07aba599b47fdd4cf788647b601ccd
    ├───libpng: github:glennrp/libpng/8439534daa1d3a5705ba92e653eda9251246dd61
    ├───nixpkgs follows input 'nixpkgs'
    ├───rust-overlay: github:oxalica/rust-overlay/b7996075da11a2d441cfbf4e77c2939ce51506fd
    │   └───nixpkgs follows input 'wezterm/nixpkgs'
    └───zlib: github:madler/zlib/cacf7f1d4e3d44d871b605da3b647f07d718623f

---

@rgruyters Before WezTerm broke during an attempted update of nixpkgs, my system flake was at revision 957d95fc8b9bf1eb60d43f8d2eba352b71bbf2be, when everything was still working.

Before davidsierradz' workaround to use Wezterm directly from the repo as a flake, I simply used the WezTerm package directly from the revision I knew to be working in the system packages, like this:

  environment.systemPackages = with pkgs; [
    # packages from a specific nixpkgs version
    (import
      (builtins.fetchTarball {
        url = "https://github.com/NixOS/nixpkgs/archive/957d95fc8b9bf1eb60d43f8d2eba352b71bbf2be.tar.gz";
        sha256 = "sha256:0jkxg1absqsdd1qq4jy70ccx4hia3ix891a59as95wacnsirffsk";
      })
      { inherit system; }).wezterm

    # official system packages
    # …

(invalidate sha256, nixos-rebuild switch and use the hash shown there)

Usually, previous package versions can be found with this website for Nix package versions. Since WezTerm must be very closely coordinated with the graphics driver in this case, the versions listed on the website unfortunately didn't work either. So I stuck with the revision I knew, which worked as long as I didn't activate WebGpu in the configuration.

[SuperSandro2000]

We now collected all workarounds and downgrades. Please don't double post them.

Also I am unwilling to provide any support when using https://lazamar.co.uk/nix-versions, as it is basically a very big hack.

Please keep this issue on topic.

[carsoncall]

I have run into the same issue; setting config.front_end = "WebGpu" fixed it for me. Let me know if any logs or other information would be useful to you, and I can provide it.

[eblume]

I have two MacOS and one NixOS machines which build from different host definitions of the same flake (albeit with some branching config per-host), and I have hit this issue today on all three machines after a nix flake update. Scanning all of the above comments, I'm not sure anyone has a clear picture yet of what the cause of this rendering issue is other than that it's related to OpenGL built via Nix, somehow. I'm reporting this because the fact that I've hit this with the same flake on both MacOS and NixOS might be new information for this thread, apologies if it is a redundant report.

[will]

@eblume for what it's worth, updating my nix-darwin stuff today caused me to run into this also. I have no linux+nix machines, just an arm mac.

[wez]

@jjpe FWIW, I haven't looked at this at all, because:

1. nixos isn't a directly-supported-by-me platform
2. @SuperSandro2000 said that it was working for him above in textures broken on NixOS master branch #5990 (comment)

My impression of this issue is that something in nixos is responsible because I can assure you that there is no logic within wezterm to decide to not work on nixos, and wezterm works everywhere else, and also reportedly ran fine on nixos previously.

I have no plans to dig into this any deeper; I do not use nixos and don't have the bandwidth to get into it.

[jjpe]

To point #2, I cannot say that it's fixed. Somehow it works for them, but that's definitely not a general thing.

In addition, since nobody (that I know of) on the nixos side has the necessary knowledge to fix this (likely not even the maintainer of the nix derivation, as that is essentially just a way to package the software), I don't believe that will be possible on their side to fix this.

Which leaves an inescapable conclusion: Wezterm will likely remain broken in nixpkgs.

I also disagree it's a nixos-only issue: MacOS is apparently also hit with this. Yes, nix is involved there, but again that's just packaging. In addition, that packaging is the same for me and others using MacOS, and yet there are differences in terms of having Wezterm working or not.
It is unclear exactly what makes the difference there though.

[yshui]

wait, this is still going on? i was pretty sure this was already fixed, and i think i even vaguely remember what the bug was. i think nixpkgs just need to bump wezterm to a newer version.

[crabdancing]

@wez Some Mac OS people are reporting the same issue, so it's probably not NixOS in itself. Although you can definitely argue it's somehow related to the Nix build process in particular -- which has Darwin support.

@jjpe If it came to that, it really woudn't be that hard to bisect commits and figure out exactly what commit introduced it, even with no understanding of the internals -- especially since Wezterm seems to have a secret flake now (though I'm not sure when that was comitted).

Worst case scenario is that it was some kind of global bump of dependencies (a la cargo update), in which case it's another goose chase, but it'd at least narrow it down enough to be workable.

@art1es23 Yeah, that looks like an aarch64-darwin issue. It's a less commonly used platform in the NixOS ecosystem, so it wouldn't surprise me if compilation breaks on it more frequently. I don't have any similar systems, so it's hard for me to help much there. I'd second the using nixpkgs stable version for now instead. :/ If it helps at all, I would like to say I've been using Nix/NixOS for quite awhile and your code looks fine at first blush.

[crabdancing]

@yshui You can do nix run 'github:wez/wezterm/main?dir=nix' to quickly fetch, compile, and run from latest master. If you have the compute, does it work on your system?

Side note, of course, the rendering stack of the machine itself unfortunately can't be captured in the build/run phases, so it could still potentially start working if that was bumped, but not work for bumping wezterm in and of itself. IDK if that's a factor or not though for this bug, but it's a useful data point.

[yshui]

@crabdancing unfortunately the nix file in wezterm repo is a little bit broken. you can see people having problem using it, example: #5990 (comment) it's probably missing some RPATHs.

[crabdancing]

@yshui ah that sucks. :/

Edit: um, I just tried nix run 'github:wez/wezterm/main?dir=nix' and it compiled and ran beautifully with no issues.

Edit -- data point: am currently on Intel Meteor Lake-P [Intel Arc Graphics], i915 driver, Wayland with NixOS 24.05 updated just yesterday.

[yshui]

oh maybe it got fixed? it has been a while since i last tried it. i'll give it a go after i finish building qtwebengine :/

edit: yep the rpath problem was fixed 👍 nice

[art1es23]

@crabdancing @jjpe @wthueb @wez Sorry for your time, everything working on ‘unstable’ with front_end=‘WebGpu’ (on my system) . Previously I accidentally created 2 .wezterm.lua files and kept trying to add to the wrong file o_O haha

[jjpe]

I decided to give nix run 'github:wez/wezterm/main?dir=nix' a try myself, since I have both a NixOS machine and a MacOS/nix M1 MacBook Pro.

Result: on both machines it works normally, I see no rendering issues whatsoever.

[yshui]

yeah i believe this has long been fixed, we just need to update the wezterm in nixpkgs...

[SuperSandro2000]

I do not know what the root cause in nixpkgs is. I can imagine that there where some regressions or unfortunate coincidences in mesa or related projects or with certain hardware acceleration features and combinations. I no longer have any issues like this but shortly after they where fixed for, me a friend had them for a week, too and then they vanished again.

yeah i believe this has long been fixed, we just need to update the wezterm in nixpkgs...

If there is a new release, we can upgrade in no time. I'm mainly waiting for that to avoid having to track nightly builds.

[jjpe]

If there is a new release, we can upgrade in no time. I'm mainly waiting for that to avoid having to track nightly builds.

@wez, sorry to disturb you again, but would you be willing to create a new release?

[wez]

I'd like to; the main thing holding me back is understanding whether wayland support is an obvious regression vs. the prior stable release. A lot has changed there and there are a few different compositors that need to be tested against.
Wayland is another target that I don't directly use, and again, have no real bandwidth for it, so I am reliant on folks providing quality feedback.

I will note, and this is probably an obviously recurring theme at this point, that I don't have much bandwidth to actively drive this process at the moment, so it is moving in fits and starts. I am dramatically outnumbered by my users so even when I spend several solid hours working triage and trying to play catchup, it is still not enough to be aware of the full extent of the current set of issues and pull requests, or to do very much about them.

What would be great is if the volume of sponsors could increase to cover funding more dedicated time. Right now the level of funding is, while greatly appreciated, not covering more than an hour or so of time per week, and it only takes one or two conversations like this one, or a couple of PR reviews, to eat up a good chunk of that time in any given week.

[thecaralice]

I had this issue on macOS using nix-darwin and home-manager, wezterm (20240203-110809-5046fc22) installed from nixpkgs; only happened after switching from using built-in JetBrains Mono to the one installed using a nix derivation. Initially suspected that the issue is the external JetBrains Mono being variable but could not find any issues about broken variable fonts. Upgrading to latest wezterm revision (using the flake) fixed the issue.

[jjpe]

Upgrading to latest wezterm revision (using the flake) fixed the issue.

What do you mean by upgrading, exactly?
Do you mean using nix run github:wez/wezterm/main?dir=nix? Or did you use an overlay?

If it is the latter case, how exactly did you overlay the new pkg?

[thecaralice]

Upgrading to latest wezterm revision (using the flake) fixed the issue.

What do you mean by upgrading, exactly? Do you mean using nix run github:wez/wezterm/main?dir=nix? Or did you use an overlay?

If it is the latter case, how exactly did you overlay the new pkg?

programs.wezterm.package = inputs.wezterm.packages.${pkgs.system}.default;

in the home-manager configuration

[SuperSandro2000]

I just noticed this error occurring on kernel 6.1 after a downgrade from 6.6.

[dkumza]

config.front_end = "WebGpu"
config.webgpu_power_preference = 'HighPerformance'

this fixed my issue

[viperML]

@dkumza but are you running wezterm in wayland without xwayland?

[samuela]

FWIW this affects the latest nixpkgs master (at least as of NixOS/nixpkgs@34a6264) on macOS.

[dkumza]

@dkumza but are you running wezterm in wayland without xwayland?

if you asking about his option:
config.enable_wayland = true
it works for me with or without it.
but it doesnt work if i set to false
im on wayland + nvidia

[Kladki]

Would like to mention that this issue isn't limited to nix, as I also started experiencing the issue on Alpine Linux after we did a rebuild on wezterm recently due to updated system libraries. Maybe the issue title could be renamed in light of this?

[xieve]

As part of upgrading my system to the latest nixpkgs/unstable as of yesterday and thus also Gnome 47, I re-tested this on my system:

• The version on nixpkgs still exhibits this issue for me on both Wayland and XWayland. Using WebGPU resolves this issue, but on Wayland, it crashes when I move the window to an (integer) scaled monitor.
• Running nix run 'github:wez/wezterm/main?dir=nix' resolves this issue completely, but then Bad appearance on wayland #5349 is back and I also experience Wezterm creates crazy large window on Wayland in Fedora 40 #5360.

[yeoffrey]

Works for me on nix-darwin as of today with this work-around. Quit wezterm and add the following to your config.

-- wezterm.lua
config.front_end = "WebGpu"

Then relaunch. All symbols loading properly.