[Suggestion] Side by side installation with old vkBasalt (to enable quick testing/adoption)

[fcaraujo]

Hey awesome work, I was not able to test it tho (but might be, running bazzite/hyprland so can be useful to testing the input block stuff if you need help) yet but I'm really interested.

That brings me to my suggestion - since I notice the env vars disclaimer, and I just started playing with vkBasalt myself and got it (kinda) working I'm wondering if it would be possible to make it happen.

My idea is basically improve traction and make it independent from the existing vkBasalt installation people might have; we could either use other vars (I'm just aware of ENABLE_VKBASALT and VKBASALT_CONFIG_FILE - any other conflicting ones) or add one to customise which bins should be target/used, idk... let's say if we have ENABLE_VKBASALT_OVERLAY=1 instead (since even the old configs are not supported we should try to be more distinctive anyways) it would not conflict aye?

Happy to help but first decided reaching out to hear your thoughts...

[Boux]

I agree, it's probably time I do this. I thought about doing this early on but I got lazy because I already had a bunch of steam games configured with the old env var. This should be pretty simple, in theory I just need to replace the names of /usr/lib/libvkbasalt.so and /usr/share/vulkan/implicit_layer.d/vkBasalt.json. For the env var, I wonder if I should just give the possibility to override ENABLE_VKBASALT with whatever, I'll explore this possibility a bit to see if it's easy, if not I'll probably just use ENABLE_VKBASALT_OVERLAY

[Boux]

Alright, it's done, i'll merge this into master branch soon, the new env vars are ENABLE_VKBASALT_OVERLAY=1 and DISABLE_VKBASALT_OVERLAY=1. As for customizing these, it was already supported since the user can just manually modify these in /usr/share/vulkan/implicit_layer.d/vkBasalt.json after installation. I'll also update the AUR package so that it doesn't mark vkBasalt as a conflict

[Boux]

@fcaraujo

Oof! i might revert this, as it creates a pretty big issue. In gamescope, there is code that detects if the ENABLE_VKBASALT variable is set, and it will prevent the vulkan layer running inside of gamescope to duplicate the vkBasalt post processing layer. If we change the env var to ENABLE_VKBASALT_OVERLAY, this detection fails and it WILL duplicate the vkBasalt layer (because gamescope itself is also a vulkan layer).

There are 3 solutions to this issue:

1. Add gamescope detection within vkBasalt_overlay to make the inner layer passthrough
2. Send a PR to upstream gamescope to also add checks for our own env var
3. Revert to ENABLE_VKBASALT, which creates a conflict with the original vkBasalt.

I'm gonna choose option 3, as it is the most simple for now

I will still keep all the changes I made (renamed the lib file and layer file) so in THEORY you could still have both versions of vkBasalt running on the same system, if you manually change the env var in /usr/share/vulkan/implicit_layer.d/vkBasalt-overlay.json, but I will make it ENABLE_VKBASALT by default

[Boux]

Turns out reverting to ENABLE_VKBASALT might be the only good solution for now, since apparently it also fixes this issue: #6

I guess there are a few things built into gamescope to prevent vkBasalt from freaking the fuck out in general and it uses the env var for that.

[fcaraujo]

Hey thanks for reporting back and letting me know.

I was able to build and use v0.1.1 on bazzite (on hyprland) and, of course i know my use case might be very simple, I was able to use it flawlessly to apply some effects on ARC Raiders without having to handle with the existing vkBasalt previously installed.

I'm sticking to it and hope you can find a way to solve that in the future, if you need help testing anything on my end just lmk @Boux, all the best. 👍