OpenXR-SDK-Source icon indicating copy to clipboard operation
OpenXR-SDK-Source copied to clipboard

on Linux, search order for layers isn't consistent with Vulkan and XDG basedir spec

Open smcv opened this issue 5 months ago • 7 comments

The search order for layers (and possibly runtimes) on Linux seems to have been copied from Vulkan before https://github.com/KhronosGroup/Vulkan-Loader/issues/246 and https://github.com/KhronosGroup/Vulkan-Loader/issues/245 were fixed in https://github.com/KhronosGroup/Vulkan-Loader/pull/655. Previous discussion of this is mostly in https://github.com/KhronosGroup/Vulkan-Loader/issues/245.

It would be good if OpenXR was consistent with the Vulkan, and the XDG base directory specification that Vulkan now obeys. Concretely, I believe this would mean changing ReadDataFilesInSearchPaths:

  • the single directory $XDG_CONFIG_HOME (defaulting to ~/.config if unset) should be searched before (higher precedence than) the first item in $XDG_CONFIG_DIRS, but it is not currently searched at all;

  • the single directory $XDG_DATA_HOME (defaulting to ~/.local/share) should be searched before (higher precedence than) the first item in $XDG_DATA_DIRS, but it is currently searched after (lower precedence than) the last item in $XDG_DATA_DIRS

Note that $XDG_CONFIG_HOME is already searched for active_runtime(.<arch>).json in FindXDGConfigFile, with the correct ordering/precedence relative to $XDG_CONFIG_DIRS.

The Vulkan loader has a really nice summary of how layers and drivers are located, in https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderLayerInterface.md#linux-layer-discovery and https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderDriverInterface.md#driver-discovery-on-linux (and they are consistent with each other). I'd suggest following similar conventions (but with suffixes like vulkan/implicit_layer.d replaced by an appropriate OpenXR equivalent) rather than having OpenXR do its own thing.

If I'm reading the C++ code correctly, I believe the two changes I suggested above would mean that searching for layers and runtimes is fully consistent with searching for Vulkan layers and drivers (searching "the config stack" followed by "the data stack"), while searching for active_runtime(.<arch>).json would be consistent with Vulkan up until the end of the "config stack", but without proceeding into the "data stack" if it is not found in a config directory.

One difference between Vulkan and OpenXR where OpenXR does have the advantage is that OpenXR describes a vocabulary of CPU architecture identifiers to look for active_runtime.<arch>.json.

smcv avatar Jan 31 '24 19:01 smcv