Vendors & Plug-ins
DisplayXR is vendor-neutral. Any 3D-display maker can ship a display-processor plug-in from their own repo — the runtime discovers and loads it at startup. You never fork the runtime.
The plug-in model
A vendor integration is a display-processor plug-in — a dynamically-loaded library that turns the rendered stereo pair into whatever a specific panel needs (lenticular weaving, interlacing, calibration) and feeds the runtime its display geometry and tracked eye positions. It ships from your repo with your installer, on your release cadence.
This is the model as of ADR-019 (issues #256 / #263). Earlier builds linked vendor drivers into the runtime tree; that approach is retired. The shipped runtime carries zero vendor SDK identifiers in its link line.
How discovery works
At xrCreateInstance the runtime enumerates registered plug-ins, loads each in probe order, and the first one whose hardware is present wins. The built-in sim_display plug-in sits last and always loses to real hardware.
Windows
Your installer registers the plug-in under HKLM\Software\DisplayXR\DisplayProcessors\<id> with a probe order and an uninstall string.
macOS / Linux
A JSON manifest in the DisplayProcessors search path points at your .dylib / .so, with the same probe-order semantics.
What you implement
One exported symbol — xrtPluginNegotiate — returning an xrt_plugin_iface that the runtime calls for:
- probe — is your hardware present?
- display info — panel dimensions, eye-tracking mode (MANAGED or MANUAL).
- display-processor factories — one per graphics API you support (D3D11, D3D12, Vulkan, Metal, OpenGL). The compositor calls your
process_atlaseach frame; it never weaves itself.
Your vendor SDK is static-linked into the plug-in only. Zero compositor changes are required.
Start from the reference
The Leia SR plug-in is a complete, shipping integration — the recommended starting point. Fork it, swap the driver for your hardware, and point the installer at your plug-in id.