tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
82.76k stars 2.48k forks source link

[bug] Empty window, Failed to create GBM device for render device: /dev/dri/renderD128 #8254

Open zyansheep opened 10 months ago

zyansheep commented 10 months ago

Describe the bug

I was trying to compile and run mdSilo-app, but kept giving me this error. I though it might be mdSilo-specific so I created a new tauri project using create-tauri-app, but it still gives me this same error:

    Building [=======================> ] 358/359: tauri-app(bin)                                      
    Finished dev [unoptimized + debuginfo] target(s) in 1m 22s
Gtk-Message: 15:21:25.493: Failed to load module "appmenu-gtk-module"
Could not determine the accessibility bus address
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: No such file or directory
Gtk-Message: 15:21:27.416: Failed to load module "appmenu-gtk-module"
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
DRI driver not from this Mesa build ('23.0.3' vs '23.1.9')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: No such file or directory
Failed to get GBM device

It doens't crash, just stays there and will continue to print "Failed to get GBM device" whenever I interact (resize) the window: Screenshot_20231118_153023

Reproduction

Repro repo: https://github.com/zyansheep/tauri-app-render-bug Instructions (on NixOS w/ nix flakes)

nix develop
yarn
yarn tauri dev

Expected behavior

Expected the app to show the default Hello World window.

Platform and versions

yarn run v1.22.19
$ tauri info

[⚠] Environment
    - OS: NixOS 23.5.0 X64
    ✔ webkit2gtk-4.0: 2.42.2
    ✔ rsvg2: 2.56.3
    ✔ rustc: 1.76.0-nightly (dd430bc8c 2023-11-14)
    ✔ cargo: 1.76.0-nightly (6790a5127 2023-11-10)
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 18.18.2
    - yarn: 1.22.19
    - npm: 9.8.1

[-] Packages
    - tauri [RUST]: 1.5.2
    - tauri-build [RUST]: 1.5.0
    - wry [RUST]: 0.24.4
    - tao [RUST]: 0.16.5
    - tauri-cli [RUST]: 1.5.3
    - @tauri-apps/api [NPM]: 1.5.1
    - @tauri-apps/cli [NPM]: 1.5.6

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite
Done in 7.78s.

Stack trace

No response

Additional context

> doas inxi -GS
System:    Kernel: 6.1.62 x86_64 bits: 64 Desktop: KDE Plasma 5.27.9 Distro: NixOS 23.05 (Stoat) 
Graphics:  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel 
           Device-2: Sunplus Innovation USB Camera type: USB driver: uvcvideo 
           Display: wayland server: X.org 1.21.1.9 driver: loaded: modesetting resolution: <missing: xdpyinfo> 
           OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2) v: 4.6 Mesa 23.0.3

Edit: I figured I should probably test some tauri apps already in nixpkgs, so I installed pot and it seems to work perfectly, despite receiving nearly the same driver and render device messages as mdSilo and the blank tauri app.

Edit 2: I cloned the pot repository and build it from scratch and I'm getting the same error, so I'm wondering if it has something to do with the way it was packaged in nixpkgs :thinking:

Edit: This was solved for me, but seems to still be an issue for other people. I have reopened the issue.

VirgileHenry commented 10 months ago

I have a similar issue, also on NixOs. The logs are :

Could not determine the accessibility bus address
DRI driver not from this Mesa build ('23.1.7' vs '23.0.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.7' vs '23.0.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.7' vs '23.0.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.7' vs '23.0.3')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD129: No such file or directory
Failed to create EGL image from DMABufs with file descriptors 23, 26 and 27
alevy commented 10 months ago

I'm getting a similar issue for cinny-desktop (a Tauri-based matrix client) from the NixOS repos. pot does not seem to work for me.

Same basic errors in both, in both cases only seeing a blank or totally transparent window.

Note that this is only happening on my laptop, not on my desktop (which has a different graphics card and CPU, and thus different drivers)

zyansheep commented 10 months ago

Note that this is only happening on my laptop, not on my desktop (which has a different graphics card and CPU, and thus different drivers)

@alevy what drivers are you using for your laptop and desktop? I'm using intel integrated graphics on my laptop and AMD Ryzen 6600 GPU on desktop (mesa drivers I think).

I recently tried messing around with my laptop graphics and for some reason now the app page opens up (and is visible) in firefox, (but I can't actually do anything like open a folder).

alevy commented 10 months ago

This is now working for me on my laptop (after an upgrade to the most recent NixOS release 23.11, so likely too many variables have changed to pin-point) and is not working on my desktop anymore (though without the same error).

My desktop is using an nvidia video driver, while my laptop is a Ryzen with built-in graphics using amdgpu drivers I think.

Will try to repro using your repository.

zyansheep commented 10 months ago

I updated to 23.11 and that seemed to have fixed the issue! I'm not sure exactly what the bug here was, but I think its safe to close this for now.

Septias commented 7 months ago

I'm experiencing this on 23.11 again

DRI driver not from this Mesa build ('23.1.9' vs '23.3.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.3')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: Illegal seek
DRI driver not from this Mesa build ('23.1.9' vs '23.3.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.3')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.3')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: No such file or directory
Failed to get GBM device

Info:

[⚠] Environment
    - OS: NixOS 23.11.0 X64
    ✔ webkit2gtk-4.0: 2.42.4
    ✔ rsvg2: 2.57.1
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 18.18.2
    - pnpm: 8.10.2
    - yarn: 1.22.19
    - npm: 9.8.1

[-] Packages
    - tauri [RUST]: 1.6.0
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.7
    - tauri-cli [RUST]: 1.5.10
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.10

[-] App
    - build-type: bundle
    - CSP: default-src 'self'; img-src * asset: https://asset.localhost; font-src *
    - distDir: ../dist
    - devPath: http://localhost:3333/
    - framework: Vue.js
    - bundler: Vite
zyansheep commented 7 months ago

Hmm, I'm happy to re-open this issue, but It might be a different error, i.e. the "Illegal Seek" part seems suspicious.

Also, if you open a new issue it might get more attention :)

FabianLars commented 7 months ago

Errors like those are usually out of our control so a new issue won't help much either unfortunately :/

Pandapip1 commented 7 months ago

Can also repro. Am also on 23.11, but am also using flakes.

bwkam commented 7 months ago

I have the same problem. Using NixOS 24.05 and cargo-tauri nixpkgs.

Could not determine the accessibility bus address
DRI driver not from this Mesa build ('23.1.9' vs '23.3.5')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.5')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.5')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: Illegal seek
DRI driver not from this Mesa build ('23.1.9' vs '23.3.5')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.5')
failed to bind extensions
DRI driver not from this Mesa build ('23.1.9' vs '23.3.5')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: No such file or directory
Failed to get GBM device

using the flake mentioned here

zyansheep commented 7 months ago

Alright looks like this is still a reoccuring issue. I will reopen.

jordan-bravo commented 7 months ago

I am also having this issue, using a Nix flake on NixOS (nixpkgs-unstable). My GPU is an Intel integrated.

Output:

❯ yarn tauri dev
yarn run v1.22.19
$ /home/jordan/scm/my-app/node_modules/.bin/tauri dev
     Running BeforeDevCommand (`npm run dev`)

> my-app@0.1.0 dev
> next dev

   ▲ Next.js 14.1.0
   - Local:        http://localhost:3000

 ✓ Ready in 1506ms
        Info Watching /home/jordan/scm/my-app/src-tauri for changes...
    Finished dev [unoptimized + debuginfo] target(s) in 0.22s
DRI driver not from this Mesa build ('24.0.1' vs '24.0.2')
failed to bind extensions
DRI driver not from this Mesa build ('24.0.1' vs '24.0.2')
failed to bind extensions
DRI driver not from this Mesa build ('24.0.1' vs '24.0.2')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: Illegal seek
Pandapip1 commented 7 months ago

It seems like this issue is related to flakes. Is anyone here not using flakes?

ryardley commented 6 months ago

Did a nix channel update and I have started seeing this error again. So I stumbled on this issue but then played around and found the following worked for me:

It went away these are the only steps I took:

1) Re-build flake.lock

I don't know if this had anything to do with it but this is the only lock file I turfed.

rm flake.lock

And then enter and exit the folder so the flake gets picked up by direnv and gets rebuilt

This wasn't enough as development was still giving me the same error. Maybe it did something though I am not sure

2) Nuke all things in the repo

I am using git so I figured I would nuke all the caches:

Making sure I am in my repo (this leaves my .git folder intact):

rm -rf *
git reset --hard HEAD
pnpm install
pnpm tauri build
pnpm tauri dev

My flake:

# From https://tauri.app/v1/guides/getting-started/prerequisites
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay.url = "github:oxalica/rust-overlay";
  };

  outputs = { self, nixpkgs, flake-utils, rust-overlay }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];

        pkgs = import nixpkgs {
          inherit system overlays;
        };

        libraries = with pkgs;[
          webkitgtk
          gtk3
          cairo
          gdk-pixbuf
          glib
          libayatana-appindicator
          dbus
          openssl_3
          librsvg
        ];

        packages = with pkgs; [
          curl
          sqlite
          wget
          pkg-config
          dbus
          openssl_3
          glib
          gtk3
          libsoup
          webkitgtk
          librsvg
          tor
          libappindicator-gtk3
          rust-bin.stable."1.76.0".default
          rust-analyzer
          sea-orm-cli
          sqlx-cli
          jq
        ];
      in
      {
        devShell = pkgs.mkShell {
          buildInputs = packages;

          shellHook =
            ''
              export LD_LIBRARY_PATH=${pkgs.lib.makeLibraryPath libraries}:$LD_LIBRARY_PATH
            '';
        };
      });
}
bwkam commented 6 months ago

Did a nix channel update and I have started seeing this error again. So I stumbled on this issue but then played around and found the following worked for me:

It went away these are the only steps I took:

1) Re-build flake.lock

I don't know if this had anything to do with it but this is the only lock file I turfed.

rm flake.lock

And then enter and exit the folder so the flake gets picked up by direnv and gets rebuilt

This wasn't enough as development was still giving me the same error. Maybe it did something though I am not sure

2) Nuke all things in the repo

I am using git so I figured I would nuke all the caches:

Making sure I am in my repo (this leaves my .git folder intact):

rm -rf *
git reset --hard HEAD
pnpm install
pnpm tauri build
pnpm tauri dev

My flake:

# From https://tauri.app/v1/guides/getting-started/prerequisites
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay.url = "github:oxalica/rust-overlay";
  };

  outputs = { self, nixpkgs, flake-utils, rust-overlay }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];

        pkgs = import nixpkgs {
          inherit system overlays;
        };

        libraries = with pkgs;[
          webkitgtk
          gtk3
          cairo
          gdk-pixbuf
          glib
          libayatana-appindicator
          dbus
          openssl_3
          librsvg
        ];

        packages = with pkgs; [
          curl
          sqlite
          wget
          pkg-config
          dbus
          openssl_3
          glib
          gtk3
          libsoup
          webkitgtk
          librsvg
          tor
          libappindicator-gtk3
          rust-bin.stable."1.76.0".default
          rust-analyzer
          sea-orm-cli
          sqlx-cli
          jq
        ];
      in
      {
        devShell = pkgs.mkShell {
          buildInputs = packages;

          shellHook =
            ''
              export LD_LIBRARY_PATH=${pkgs.lib.makeLibraryPath libraries}:$LD_LIBRARY_PATH
            '';
        };
      });
}

Tried the same steps (except that I'm using vanilla js) but I got the same error.

Pandapip1 commented 6 months ago

Also tried the same steps.

Interestingly, I'm getting this error with plain rust, adwaita, and gtk4. I think this might be an upstream issue.

michelrandahl commented 6 months ago

Same issue for me using NixOs 23.11 and with a flake that is very similar to the one that ryardley presented. I was looking to just learn about Tauri for the first time... Is there perhaps an older version that works with NixOs 23.11?

zluo01 commented 6 months ago

It also happens on Fedora 39 with KDE. It works when running through tauri dev but once I build it with tauri build , the app image behaves the same as shown above.

[✔] Environment
    - OS: Fedora 39 X64
    ✔ webkit2gtk-4.0: 2.44.0
    ✔ rsvg2: 2.57.1
    ✔ rustc: 1.73.0 (cc66ad468 2023-10-03)
    ✔ cargo: 1.73.0 (9c4383fb5 2023-08-26)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 21.0.0
    - npm: 10.2.0

[-] Packages
    - tauri [RUST]: 1.6.1
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.7
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite
Septias commented 6 months ago

It's funny to mention, though, that the underlying app stays responsive and works even though the screen is blank

abraverm commented 6 months ago

I have the same issue and WEBKIT_DISABLE_COMPOSITING_MODE=1 fixed it for me (without any other actions).

LukaOber commented 6 months ago

I got the same problems and fixed them when using this flake.nix

I also set WEBKIT_DISABLE_COMPOSITING_MODE=1, but I don't know if that was necessary.

There are most likely some unnecessary parts in this flake.nix, so feel free to cut some things out.

inputs = {
    nixpkgs.url = "nixpkgs";
    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay.url = "github:oxalica/rust-overlay";
  };

  outputs = { self, nixpkgs, rust-overlay, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];
        pkgs = import nixpkgs {
          inherit system overlays;
        };

        libraries = with pkgs;[
          webkitgtk
          webkitgtk_4_1
          gtk3
          cairo
          gdk-pixbuf
          glib
          dbus
          openssl_3
          librsvg
          libsoup
          xdo
          xdotool
        ];

        packages = with pkgs; [
          (rust-bin.selectLatestNightlyWith (toolchain: toolchain.default.override {
            extensions = [ "rust-src" "rust-analyzer" ];
            targets = [ "wasm32-unknown-unknown" ];
          }))
          curl
          wget
          pkg-config
          dbus
          openssl_3
          glib
          gtk3
          libsoup
          webkitgtk
          webkitgtk_4_1
          librsvg
          xdo
          xdotool
        ];
      in
      {
        devShell = pkgs.mkShell {
          buildInputs = packages;

          shellHook =
            ''
              export LD_LIBRARY_PATH=${pkgs.lib.makeLibraryPath libraries}:$LD_LIBRARY_PATH
              export XDG_DATA_DIRS=${pkgs.gsettings-desktop-schemas}/share/gsettings-schemas/${pkgs.gsettings-desktop-schemas.name}:${pkgs.gtk3}/share/gsettings-schemas/${pkgs.gtk3.name}:$XDG_DATA_DIRS
            '';
        };
      });
}
Septias commented 6 months ago

Setting WEBKIT_DISABLE_COMPOSITING_MODE=1 also fixed it for me. Here is a short snippet to create a wrapped output binary:

wrapProgram $out/bin/${name} --prefix PATH : ${pkgs.glib}/bin --set WEBKIT_DISABLE_COMPOSITING_MODE 1
jeffguorg commented 5 months ago

same issue here.

i'm not 100pct sure but it seems like a nix issue. nix link tauri product to a different version of some library with the system, maybe compositor or X compositing library, the protocol may vary and thus built app cannot render web page on screen.

My First Try: without flakes i set nixpkgs reference by 1. nix-channel --remove nixpkgs # and any other channels 2. nixos configuration: ```nix environment.etc."channels/nixpkgs".source = nixpkgs.outPath; environment.etc."channels/nixpkgs-unstable" = lib.mkIf (nixpkgs-unstable != null) { source = nixpkgs-unstable.outPath; }; nix.nixPath = [ "nixos=/etc/channels/nixpkgs" "nixpkgs=/etc/channels/nixpkgs" "nixpkgs-unstable=/etc/channels/nixpkgs-unstable" ]; ``` it replaced nix channel used before. and force nixpkgs to be synced with nixos flake then i build tauri by use default.nix, without flake which is previously hard to keep sync with system. if you set nix.nixPath like above, use /etc/channels/nixpkgs as flake inputs ```nix # mostly copied from https://github.com/NixOS/nixpkgs/blob/ab3fc0538d2012d5da74fb6a28c78f2c37831998/pkgs/by-name/po/pot/package.nix # first line changed to build default.nix out of nixpkgs tree # you can also nix-build --expr '(import {}).callPackage ./default.nix {}' { pkgs ? import {}, ... }: pkgs.callPackage ({ lib , stdenv , stdenvNoCC , rustPlatform , fetchFromGitHub , wrapGAppsHook , cargo , rustc , cargo-tauri , pkg-config , nodePackages , esbuild , buildGoModule , jq , moreutils , libayatana-appindicator , gtk3 , webkitgtk , libsoup , openssl , xdotool , cacert }: stdenv.mkDerivation rec { pname = "my-brand-new-tauri-app"; version = "0.0.0"; # this ensures that source files lines in /nix/store/[HASH]-source directory, which makes unpackPhase copy source files to source sub directory, and let you use sourceRoot = "source/src-tauri" src = lib.cleanSourceWith { src = ./.; }; sourceRoot = "source/src-tauri"; postPatch = '' substituteInPlace $cargoDepsCopy/libappindicator-sys-*/src/lib.rs \ --replace "libayatana-appindicator3.so.1" "${libayatana-appindicator}/lib/libayatana-appindicator3.so.1" ''; pnpm-deps = stdenvNoCC.mkDerivation { pname = "${pname}-pnpm-deps"; inherit src version; nativeBuildInputs = [ jq moreutils nodePackages.pnpm cacert ]; installPhase = '' export HOME=$(mktemp -d) pnpm config set store-dir $out # use --ignore-script and --no-optional to avoid downloading binaries # use --frozen-lockfile to avoid checking git deps pnpm install --frozen-lockfile --no-optional --ignore-script # Remove timestamp and sort the json files rm -rf $out/v3/tmp for f in $(find $out -name "*.json"); do sed -i -E -e 's/"checkedAt":[0-9]+,//g' $f jq --sort-keys . $f | sponge $f done ''; dontFixup = true; outputHashMode = "recursive"; outputHash = "sha256-6CxFm4m3WphdRgU+O8qUHgb+ntdmLrP3zMdJvEnFZcg="; }; # pot uses a seperate Cargo.lock file, i changed it to the one in the source tree cargoDeps = rustPlatform.importCargoLock { lockFile = ./src-tauri/Cargo.lock; outputHashes = { # All other crates in the same workspace reuse this hash. #"tauri-plugin-autostart-0.0.0" = "sha256-/uxaSBp+N1VjjSiwf6NwNnSH02Vk6gQZ/CzO+AyEI7o="; }; }; nativeBuildInputs = [ rustPlatform.cargoSetupHook cargo rustc cargo-tauri wrapGAppsHook nodePackages.pnpm pkg-config ]; buildInputs = [ gtk3 libsoup libayatana-appindicator openssl webkitgtk xdotool ]; # no idea why this does not work #ESBUILD_BINARY_PATH = "${esbuild}/bin/esbuild"; ESBUILD_BINARY_PATH = "${lib.getExe (esbuild.override { buildGoModule = args: buildGoModule (args // rec { version = "0.18.20"; src = fetchFromGitHub { owner = "evanw"; repo = "esbuild"; rev = "v${version}"; hash = "sha256-mED3h+mY+4H465m02ewFK/BgA1i/PQ+ksUNxBlgpUoI="; }; vendorHash = "sha256-+BfxCyg0KkDQpHt/wycy/8CTG6YBA/VJvJFhhzUnSiQ="; }); })}"; preBuild = '' export HOME=$(mktemp -d) pnpm config set store-dir ${pnpm-deps} chmod +w .. pnpm install --offline --frozen-lockfile --no-optional --ignore-script chmod -R +w ../node_modules pnpm rebuild # Use cargo-tauri from nixpkgs instead of pnpm tauri from npm cargo tauri build -b deb ''; preInstall = '' mv target/release/bundle/deb/*/data/usr/ $out ''; }) {} ```
Flakes can work then i just found that if i use same branch of nixpkgs in flake with system, it may also work. my nixos is on `nixpkgs/release-23.11`, if i set this in the flake.nix for app ```nix { inputs.nixpkgs.url = "nixpkgs/release-23.11"; } ``` it also works

i guess that's why most system freeze the package versions.

Pandapip1 commented 5 months ago

For everybody using flakes:

  1. Make sure that the version of nixpkgs being used in the flake.lock matches the one being used by the system.
  2. If you are using oxalica/rust-overlay, make sure that inputs.nixpkgs.follows is set correctly!
  3. Run nix flake lock --override-input nixpkgs github:nixos/nixpkgs/$(nixos-version --hash) in the project directory to sync the project's nixpkgs with the system version!
inputs = {
    ...
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs.nixpkgs.follows = "nixpkgs";
    };
};

The root cause of this is a mismatched version of one of the graphics libraries (likely mesa). Mesa versions are not backwards compatible!

Rashik4567 commented 4 months ago

Error produced on Fedora 41, Kde plasma 6.1(beta), wayland on nvidia.

Tauri info:


~  bun run tauri info

$ tauri info

[✔] Environment
    - OS: Fedora 41 X64
    ✔ webkit2gtk-4.0: 2.44.1
    ✔ rsvg2: 2.57.1
    ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
    ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
    ✔ rustup: 1.26.0
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 22.2.0
    - npm: 10.7.0
    - bun: 1.1.10

[-] Packages
    - tauri [RUST]: 1.6.7
    - tauri-build [RUST]: 1.5.2
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - @tauri-apps/api [NPM]: 1.5.6
    - @tauri-apps/cli [NPM]: 1.5.14

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite

Error:

libEGL warning: egl: failed to create dri2 screen
DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.

followed by:

** (test_package:12569): WARNING **: 12:16:07.668: webkit_settings_set_enable_offline_web_application_cache is deprecated and does nothing.
Failed to get GBM device 

Failed to get GBM devide occurs every time you do something on the window (cursor move, click etc). How ever, if you go to your web browser view on http://localhost:1420/ , you won't see any errors. So, its most likely a rendering issue on the frontend application.

Application remains blank if the error is thrown.

Septias commented 4 months ago

Have you tried to install the nvidia nouveau driver?

ndom91 commented 2 months ago

This comes up for me when I bump the nix mesa.drivers in my opengl settings.

My hypothesis is that it literally is just a version mismatch between the system mesa and one that (a) tauri is using or (b) tauri is expecting the APIs for/from.

I'm pretty sure that WEBKIT_DISABLE_COMPOSITING_MODE env var would disable hardware acceleration which would also support this hypothesis.

So long story short, if we knew where this mesa error inside tauri was coming from, i.e. from which dependency, we could override the derivation, no? :thinking:

ndom91 commented 2 months ago

Okay so after letting webkitgtk compile for what felt like foreverrrr that did seem to pay off :sweat_smile:

My devshell for the tauri app now forces webkitgtk to use the same unstable.mesa version as my system and I no longer get the version mismatch or any other of the errors mentioned above.

(webkitgtk.overrideAttrs (old: {
  buildInputs = [ unstablePkgs.mesa ] ++ old.buildInputs;
}))
AkechiShiro commented 2 months ago

Is there any official fix from tauri devs ? or workaround ? @martinfrances107 @tweidinger @chippers Should we report upstream this issue to Mesa devs ?

I understand that @ndom91 fix works well on NixOS and that's pretty cool to have that possible but an official fix should be made for all Linux users at some point.

I believe this issue is not Nix/NixOS specific but happens on all Linux distros.

neunenak commented 2 months ago

I'm running into this same issue on Arch Linux (no nixos), and manually setting WEBKIT_DISABLE_COMPOSITING_MODE fixed it for me, although I still see the following errors when I run the AppImage build artifact that cargo tauri build emits:

 WARNING **: 20:47:45.121: webkit_settings_set_enable_offline_web_application_cache is deprecated and does nothing.
DRI driver not from this Mesa build ('24.1.2' vs '24.1.2-arch1.1')
failed to bind extensions
DRI driver not from this Mesa build ('24.1.2' vs '24.1.2-arch1.1')
failed to bind extensions
DRI driver not from this Mesa build ('24.1.2' vs '24.1.2-arch1.1')
failed to bind extensions
Failed to create GBM device for render device: /dev/dri/renderD128: Illegal seek

My cargo tauri info output:

➤ cargo tauri info
WARNING: no lock files found, defaulting to npm

[✔] Environment
    - OS: Arch Linux Rolling Release X64
    ✔ webkit2gtk-4.0: 2.44.2
    ✔ rsvg2: 2.58.1
    ✔ rustc: 1.77.1 (7cf61ebde 2024-03-27)
    ✔ cargo: 1.77.1 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.1 (2024-05-07)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 22.3.0
    - pnpm: 9.4.0
    - yarn: 1.22.22
    - npm: 10.8.1

[-] Packages
    - tauri [RUST]: 1.7.1
    - tauri-build [RUST]: 1.5.3
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - tauri-cli [RUST]: 1.6.0
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 1.6.0

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../src
    - devPath: ../src
ndom91 commented 2 months ago

Just FYI @neunenak by disabling compositing mode I believe you're just going back to software rendering. Which does work apparently, right, but you're missing out on a lot of performance..