KhronosGroup / KhronosGroup/OpenXR-Docs
Common handle requirement missing for nested structs
- Dominant language
- Python
- Stars
- 181
- Forks
- 74
- PR merge metrics
- No merged PRs in 30d
Description
In the Valid Usage (Implicit) of [`XrCompositionLayerCubeKHR`](https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrCompositionLayerCubeKHR) it says "Both of `space` and `swapchain` **must** have been created, allocated, or retrieved from the same [XrSession](https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrSession)"
But for the other types of composition layers, this validity requirement is missing.
This seems like an oversight.
This is presumably because the handles in the other layers are not contained in the layer struct directly, but in a different (nested) struct.
E.g. [`XrCompositionLayerProjection`](https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrCompositionLayerProjection) contains pointers to potentially multiple [`XrCompositionLayerProjectionView`](https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrCompositionLayerProjectionView)s which contain a [`XrSwapchainSubImage`](https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrSwapchainSubImage) which contains a `swapchain`.
I haven't checked if there are structs other than the composition layers that are affected by this.
The validity requirement is generated [here](https://github.com/KhronosGroup/OpenXR-Docs/blob/f3f9358d4975cbac3dcb3c2b8efe2917a295821c/specification/scripts/validitygenerator.py#L936) but it only seems to check handles that are directly in the struct.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in specification/scripts/validitygenerator.py around line 936 and inspect how validity requirements are generated for handles nested in composition-layer structures. Compare the generated requirements for the linked OpenXR types and determine which affected structs are missing the same-session requirement; done means the generator covers those cases and the resulting specification text includes them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100