matrixfurry.com
The open source OpenXR runtime
1# Spaces in Monado design {#design-spaces}
2
3<!--
4Copyright 2022-2023, Collabora, Ltd. and the Monado contributors
5SPDX-License-Identifier: BSL-1.0
6-->
7
8## Goals
9
10* Hold a super set of the semantic spaces that OpenXR requires, local, stage,
11 unbounded, etc...
12* Allow devices to be attached to other devices.
13* Generating events when a space is moved, dealing with the requirement that
14 the move only happens after a certain time in the future.
15* Make the internal graph be simple and non-cyclic.
16 * No bi-directional links.
17 * Always have a root object.
18
19## Overall design
20
21The `xrt_space` object is fairly straight forward, it's a space. Some have
22semantic meaning like local, stage, unbounded. The `xrt_space_overseer` object
23is where most of the interesting things happens. By having a separate object
24where functionality is implemented we can handle things like: different sessions
25with different spaces, have a object that space events comes from. It also makes
26it easier for the IPC layer to implement it.
27
28## Issues & questions
29
30* Where do space events come from?
31 * **UNRESOLVED:** Probably will come from the space overseer.
32* Do we map all spaces one to one, like the each `XrSpace` with an offset gets
33 backed with an `xrt_space`. There is going to be a limit on spaces from the
34 point of view of the IPC layer, do we create some of them locally?
35 * **RESOLVED:** While you can create a offset `xrt_space`, the offsets from
36 from the `XrSpace`s are not expressed as an `xrt_space` this is to reduce
37 the number of spaces created.
38* For the IPC gap do we mirror the entire space graph between the app side and
39 the service side. Or is it enough to only expose the spaces/nodes a app needs
40 and keep all of the links on the service side only.
41 * **RESOLVED:** The graph is kept opaque from the application (and all other
42 parts of Monado, an space overseer has greater freedom in how to configure
43 the space graph).