mangohud: add bitness suffix to layer name #231874
Conversation
The VK loader finds the 32-bit layer first and does not attempt to load the 64-bit layer afterwards; likely because it shares the same name. Simply giving them different names fixes the issue; both layers are tried and the correct one succeeds. A similar patter is employed by obs-vkcapture which continued working after NixOS#228870. Fixes NixOS#230978
| substituteInPlace $out/share/vulkan/implicit_layer.d/MangoHud.${layerPlatform}.json \ | ||
| --replace "VK_LAYER_MANGOHUD_overlay" "VK_LAYER_MANGOHUD_overlay_${toString stdenv.hostPlatform.parsed.cpu.bits}" |
There was a problem hiding this comment.
I don't have the means to test but if MangoApp needs this too, the file should be modified here aswell when support is enabled.
cc @Scrumplex
There was a problem hiding this comment.
Yep, this should be done for MangoApp too!
There was a problem hiding this comment.
Right now our current build isn't even supporting mixed 32bit & 64bit mangoapp (and I don't think upstream does either). Since it runs in a separate process, there's no need to have a 32bit build for overlaying 32bit games (on a 64bit system).
|
Maybe we can get this upstreamed? Shouldn't be hard to add the arch suffix directly to the template. |
This allows the user to disable 32-bit support for closure size reasons or in order to mitigate loader issues like NixOS#230978. The name is weird because it can't start with a digit :/
Atemu
force-pushed
the
fix/mangohud-layer-name-bitness
branch
from
c3483ff
to
7eacc7f
Compare
ofborg
bot
added
10.rebuild-darwin: 0
|
Hi @Atemu @kira-bruneau I'm happy to test this, but unsure of how I can do so? Should I replace nixpkgs reference in my flake.nix with this branch Atemu:fix/mangohud-layer-name-bitness? |
|
It works like a charm! Thank you @Atemu |
|
@THERAAB I don't use flakes but I'd expect that to work. Overriding the NIX_PATH would be the non-flakes way of doing it. My branch is based on last week's unstable. |
Description of changes
The VK loader finds the 32-bit layer first and does not attempt to load the
64-bit layer afterwards; likely because it shares the same name. Simply giving
them different names fixes the issue; both layers are tried and the correct one
succeeds.
A similar patter is employed by obs-vkcapture which continued working after
#228870.
Fixes #230978
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)