Running kitty with nixGL causes all software ran under it to gain nixGL status.
soupglasses opened this issue · 9 comments
When running kitty such as nix run github:guibou/nixGL#nixGLIntel -- kitty, it causes all programs run inside it to also get the nixGL treatment. This causes issues with system tooling such as vainfo.
Are there any ways to avoid recursive nixGL for everything ran inside of kitty?
Output of distro's `vainfo` when ran under `nixGLIntel kitty`
~ % vainfo
libva info: VA-API version 1.14.0
libva info: Trying to open /nix/store/7fzjsr2xh13lvvr7545jqw41nskxvpf5-intel-media-driver-22.5.0/lib/dri/iHD_drv_video.so
libva error: /nix/store/7fzjsr2xh13lvvr7545jqw41nskxvpf5-intel-media-driver-22.5.0/lib/dri/iHD_drv_video.so has no function __vaDriverInit_1_0
libva info: Trying to open /nix/store/v4a1c7m02rp9f829zzl7nc1c7mpgxpg9-intel-vaapi-driver-2.4.1/lib/dri/iHD_drv_video.so
libva info: Trying to open /nix/store/aw89k5734z3z60lkl0mxzz58lc6xrqhr-intel-vaapi-driver-2.4.1/lib/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /nix/store/7fzjsr2xh13lvvr7545jqw41nskxvpf5-intel-media-driver-22.5.0/lib/dri/i965_drv_video.so
libva info: Trying to open /nix/store/v4a1c7m02rp9f829zzl7nc1c7mpgxpg9-intel-vaapi-driver-2.4.1/lib/dri/i965_drv_video.so
libva error: /nix/store/v4a1c7m02rp9f829zzl7nc1c7mpgxpg9-intel-vaapi-driver-2.4.1/lib/dri/i965_drv_video.so has no function __vaDriverInit_1_0
libva info: Trying to open /nix/store/aw89k5734z3z60lkl0mxzz58lc6xrqhr-intel-vaapi-driver-2.4.1/lib/dri/i965_drv_video.so
libva error: dlopen of /nix/store/aw89k5734z3z60lkl0mxzz58lc6xrqhr-intel-vaapi-driver-2.4.1/lib/dri/i965_drv_video.so failed: /nix/store/aw89k5734z3z60lkl0mxzz58lc6xrqhr-intel-vaapi-driver-2.4.1/lib/dri/i965_drv_video.so: wrong ELF class: ELFCLASS32
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exitCurrently i am running this in my .bashrc to fix it. I do not know if there is any problems with this approach:
# Use system libva/libgl/ld by default over nix versions.
unset LIBVA_DRIVERS_PATH LIBGL_DRIVERS_PATH LD_LIBRARY_PATH __EGL_VENDOR_LIBRARY_FILENAMESThat's a good question.
Your approach is good, but it can lead to error if these values are set by the outside world to something else. For example, you will miss everything LD_LIBRARY_PATH.
The perfect solution would be to restore the value to what they were before starting nixGL.
It could be possible to also export a NIXGL_BACKUP_LD_LIBRARY_PATH (for example) which you may use to restore the previous value.
Your approach works, so as long as you do not have any issue with it, that's fine. If you need the second implementation, tell me.
Fedora does not seem to set any of these automatically. And for me who uses zsh for my terminal, I can specifically target this only under zshrc.
My primary worry about this would be that nixGL runs a program that launches a bash shell, which then pulls from ~/.bashrc and undo-es itself when you dont want it to. However i cannot think up any real world case where this would happen, but it is possible.
What could work would be a tamper-seal, some IN_NIXGL=1 value that could be hooked into. Then it would be easy to spot and revert this at a terminal level, ala. if IN_NIXGL and INTERATIVE_TERMINAL then unset .... Seems like a decent solution, as I dont know where else this could pose a problem.
I am having exactly the same three errors in the issue description (... __vaDriverInit_1_0, ... __vaDriverInit_1_0, ... ELFCLASS32) happen , when I run google-chrome-stable (non-nix) from my nixGLInteled alacritty (from nixpkgs) terminal.
My primary worry about this would be that nixGL runs a program that launches a bash shell, which then pulls from ~/.bashrc and undo-es itself when you dont want it to. However i cannot think up any real world case where this would happen, but it is possible.
I also have this concern.
The perfect solution would be to restore the value to what they were before starting nixGL.
perfect
Is there always a way to restore or unset? I think there are (at least) two scenarios where there isn't:
- e.g.
nixGLed software that is not a terminal emulator (e.g. lutris) tries to launch some other process withsh? In that case it would be non-interactive and non-login, no initialization files would get read. - sometimes applications (e.g. see this and this) do not even call shells when interacting with the OS .
However, I don't know what nixGL can really do in these scenarios. I'm not sure what causes the nix openGL problems, maybe the perfect solution involves each nix package fixing them themselves.
If you need the second implementation, tell me.
I would like this. Apart from nixGL, my shell's environment does not have these env vars set. However, having this implementation would give me peace of mind by making my setup more future-proof e.g. if future versions of my distro set them.
Well NixGL does not do a lot. It primarily just sets some variables that i unset above. https://github.com/guibou/nixGL/blob/d4fb83ca17c88444a956f8164cc3fd6cfa8291fe/nixGL.nix#L146-L155
One idea could be that software could run by default without the export part? So it executes with LIBGL_DRIVERS_PATH="..." LIBVA_DRIVERS_PATH="..." __EGL_VENDOR_LIBRARY_FILENAMES="..." LD_LIBRARY_PATH="..." ${program}?
This could help the recursion trouble.
I just tested the LIBGL_DRIVERS_PATH="..." LIBVA_DRIVERS_PATH="..." __EGL_VENDOR_LIBRARY_FILENAMES="..." LD_LIBRARY_PATH="..." ${program} idea. It does not help and kitty still keeps the variables. :/
Same problem if you are running a Hyprland using nixGL
i seem to also have this issue when running hyprland through nixGL. i use void linux so for now i decided to use the xbps-src template. i installed hyprland through nix because they have a more recent version in the unstable repo. i'm assuming that putting @soupglasses unset command as an environment variable in hyprland.conf would not solve this problem?