Change:
# The credentials should be stored in a secure keychain already, so the benefit of this is questionable # in the first place. rm -rf $out/lib/vscode/resources/app/node_modules/vscode-encrypt <ins> # Unbundle libglvnd as VSCode doesn't include libGLESv2.so.2 which is necessary for GPU acceleration rm -rf $out/lib/vscode/libGLESv2.so </ins> '') + '' runHook postInstall '';

Discussion:
I've been trying to see why vscode had rather laggy scrolling and high cpu usage when scrolling on wayland with set to 1, and upon discovering and , I saw that the library isn't found by it, causing the app to fall back to software rendering. Disabling the env variable and starting vscode like that shows that on xwayland it does start up with gpu acceleration. Doing the same thing described , VScode does start with GPU acceleration working. and no longer complains about the library Steps to reproduce the behavior: VScode with set and with the flag, so it starts with wayland support and outputs details about the startup and other stuff how it complains about the library. to see check that it's indeed using software rendering. The library is found, there are no complaints, and GPU acceleration is enabled. I am on an Intel laptop. Please run and paste the result.
Whats the exact log? vscode vendors that library and it is located in our package at
Relevant lines from [(44)] Failed to load GLES library: cannot open shared object file: No such file or directory [(186)] Exiting GPU process due to errors during initialization [(44)] Failed to load GLES library: cannot open shared object file: No such file or directory [(186)] Exiting GPU process due to errors during initialization
Same error happens on VSCodium where running with on Wayland frequently crashes on startup. ing yields a lot of lines before the logged error, including this particularly interesting one: The file doesn't actually exist, only does, so apparently VSCodium is looking for while only is vendored. If is to the , is found as a symlink to the actual library and ing again confirms that this library is loaded by VSCodium. Edit: Adding to fails with different error messages, so probably there's something broken with the vendored library:
I would guess that's because the drivers to not abi match. I would recommend to rm the vendored shared object and symlink libglvnd to the correct location. Also we should investigate if we can remove/replace the other vendored libraries.
Adding to the library path did the trick for me, thanks!
I can't get it to work with vscode sadly. vscode = (super: { libPath = lib.makeLibraryPath [pkgs.libglvnd]; });
How soon will the changes get into nixos-unstable?

2 days max ?
You can follow the PR here:
This is still broken for me: In fact, that file is missing. is missing too. As expected, due to last PR merged. I can confirm that the wrapper script contains: So what gives? How did this work for others but not me?
I'm guessing the last PR fixed it for wayland/ but broke it for others? Edit: I can confirm that I have gpu acceleration when I pin vscode nixpkgs to which is the parent commit of . I also tried the following, linking libglvnd's libGLESv2 into vscode directory. The error changed and terminal rendering completely broke with a black screen:
please open a bug !