Luboš V.

> This is kind of difficult to review, because it's doing a lot of stuff in one PR, and the commit history reflects the order you made your changes rather...

@iwubcode I did the changes you requested. There are just two unanswered things to resolve or keep it as it is: * The OpenXR externals is a collection of SDKs...

I am not willing to continue developing it as a fork. Proper VR integration needs at least an half year of development. Merging that amount of code would be practically...

Both suggested solutions feels for me not the right way to go. Could you maybe specify which parts of frontend changes you find problematic? Maybe we can find a compromis...

Thank you, much appreciated. What are the next steps for merging?

> It's still not clear to me how the Dolphin framebuffer contents are getting into the OpenXR swapchain. It is not using Dolphin's framebuffer contents. Dolphin is using OpenXR's framebuffer....

I am tending to make from the `DolphinVR` a proper class and move the reference to `Core/System.h`. Maybe I should rename it to make clear that it is the top...

I believe it is better to have all OpenXR related stuff in one directory than spreading it over several components. Imagine Apple introduced XrKit as an alternative to OpenXR and...

@iwubcode the approach with adding it to Core/System.h would make impossible to keep `OXR_CheckErrors` (which would be a huge step back for debugging possibilities). I would love to merge it...

Passing XrInstance into macro is problematic if it is not static (it is currently passed as `s_module_base` into the `OXR_CheckErrors` method). Thank you for informing me, I will hold the...