Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect the XDG base directory specification’s environment variables #723

Closed
linkmauve opened this issue Aug 19, 2017 · 9 comments
Closed
Labels
Feature An improvement or feature

Comments

@linkmauve
Copy link

As of 177d595, RenderDoc creates a ~/.local/share/vulkan/implicit_layer.d/renderdoc_capture.json file, no matter the value of $XDG_DATA_HOME.

It should first check the value of $XDG_DATA_HOME, if it’s an absolute path create the file in $XDG_DATA_HOME/vulkan/implicit_layer.d/renderdoc_capture.json, otherwise use the curent path.

See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables for more information.

@baldurk baldurk added Unresolved Waiting for a fix or implementation Feature An improvement or feature labels Aug 19, 2017
@baldurk
Copy link
Owner

baldurk commented Aug 22, 2017

This should be fixed on v1.x now - if $XDG_DATA_HOME is set and exists as a path it's used in preference.

Please check this on the latest v1.x nightly build or compile manually from v1.x, and let me know if you have any further issues.

@baldurk baldurk added status: fix to be verified and removed Unresolved Waiting for a fix or implementation labels Aug 22, 2017
@linkmauve
Copy link
Author

I just tested, there is still one issue which is when the user manually sets $XDG_DATA_HOME to a non-existent directory, for testing or for greater separation, it is ignored altogether.

The solution would be to replace FileIO::exists(xdg) with a check that the path is just absolute, since that’s the only requirement.

@baldurk
Copy link
Owner

baldurk commented Aug 30, 2017

Is there anything to clarify explicitly what the behaviour should be? The spec isn't worded well, the only time it mentions directories existing or being created is at the end which seems to only refer to $XDG_RUNTIME_DIR which is a bit different.

It wouldn't be useful to set the dir to something unique or different to any other application, since then the layer wouldn't get picked up by the loader when the vulkan application runs.

@baldurk
Copy link
Owner

baldurk commented Mar 6, 2018

v1.0 has now released, including the change as described above.

@baldurk baldurk closed this as completed Mar 6, 2018
@nyorain
Copy link

nyorain commented Mar 18, 2018

The vulkan shader cache and other files are still stored/expected in ~/.renderdoc. I guess this function would have to change. Probably best to use XDG_CONFIG_HOME since some config files seem to be stored there but then the shader cache would be a bit out of place.

@linkmauve
Copy link
Author

Shader cache would have to go into $XDG_CACHE_HOME/renderdoc/ instead.

@shmerl
Copy link

shmerl commented Jul 14, 2019

I was testing renderdoc 1.2 recently, and it still creates $HOME/.renderdoc/vkshaders.cache. Is it fixed in 1.4? Debian testing is still a bit behind the last version due to freeze.

If XDG variables are not set, the cache should go into $HOME/.cache/renderdoc, config should go to $HOME/.config/renderdoc and runtime data if any in $HOME/.local/share/renderdoc.

@astralchan
Copy link

astralchan commented Jan 22, 2024

The current code creates ~/.renderdoc. If XDG compliance is desired, it's typically read via:

configPath <- getenv(XDG_CONFIG_HOME)
if configPath is NULL
    configPath <- getenv(HOME) + ".config"

configPath += "renderdoc"

At the moment, that line of code from earlier I linked always does:

rdcstr ret = homedir + "/.renderdoc/";

@baldurk
Copy link
Owner

baldurk commented Jan 22, 2024

Please do not comment on old issues that have been closed.

If you are encountering a bug or are requesting a feature please open a new issue. You can reference this issue if you wish, but opening a new issue prevents any confusion of accidentally linking two unrelated issues and means that each issue can be handled in a clean process.

Repository owner locked as resolved and limited conversation to collaborators Jan 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Feature An improvement or feature
Projects
None yet
Development

No branches or pull requests

5 participants