KhronosGroup / KhronosGroup/OpenXR-SDK-Source

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

Open
#451 9 comments 0 reactions 0 assignees View on GitHub
synced to gitlab
Dominant language
Python
Stars
825
Forks
306
Avg merge
1d 23h
Merged PRs (30d)
1

Description

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](https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) 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(.).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(.).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..json`.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by inspecting ReadDataFilesInSearchPaths and FindXDGConfigFile, then compare their Linux search ordering with the linked Vulkan loader issue and pull request. Done means XDG_CONFIG_HOME and XDG_DATA_HOME have the stated precedence for layer and runtime discovery, while active_runtime files retain their described config-stack behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, linux
Domain
operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.