In a series of posts from February 8th to 11th, open source developer Matthieu Bucchianeri started making allegations that Meta’s OVRPlugin is blocking non-Meta OpenXR runtimes, thereby undermining the open and interoperable spirit of OpenXR. He claims that “the OVRPlugin takes intentional precautions to exclude non-Meta platforms. This means that XR content developed with OVRPlugin will only work with Quest Link, and it will not work with any other runtime.” Bucchianeri’s allegation is that if a PCVR game includes Meta’s OVRPlugin as their OpenXR middleware and doesn’t implement the counter-blocking measures that he details, then PCVR users will only be able to use a Quest headset with Quest Link while other non-Meta headsets like “Pimax, Pico, Varjo, Vive” will be blocked, even if they have conformant OpenXR runtimes. Bucchianeri has validated these blocking counter-measures, and he says, “as proven with many applications using OVRPlugin with counter-measures enabled, these applications can run on a conformant OpenXR implementation.”
Not very many XR developers are willing to speak about these issues on the record, but I did manage to record a Voices of VR podcast interview with Virtual Desktop’s Guy Godin who was able to independently corroborate many of the core allegations from Bucchianeri. Godin collaborated with Bucchianeri on the Virtual Desktop OpenXR (VDXR) runtime, but has also been receiving many complaints from PCVR users around Meta’s OpenXR non-compliance issues, especially with games that launch both on Quest and PCVR and use Meta’s OVRPlugin. Godin told me that games will work fine natively on the Quest, but any non-Quest headsets or if they aren’t using Quest Link will be blocked on the PCVR version, unless the developer specifically implements anti-blocking counter-measures detailed by Bucchianeri in his technical write-up.
It appears as though OpenXR conformance from the Khronos Group only pertains to the actual OpenXR runtimes on the hardware, but headset manufacturers are able to create their own SDK plug-in middleware that interfaces with OpenXR that doesn’t have the same conformance requirements. It appears as though Meta is able to technically maintain their OpenXR runtime conformant status because it does not apply to their OVRPlugin middleware SDK solution, and Bucchianeri is claiming that Meta is undermining the normative standards of interoperability by not following the best practices from the Khronos Group. He says, “For the past several years, Khronos has come up with best practices and solutions to develop OpenXR applications and maximize cross-vendor and cross-platform interoperability. Khronos has asked XR developers all over the world to follow these best practices, however – Meta – the largest vendor in Khronos is refusing to follow these best practices.”
Bucchianeri is also claiming to have had private communications with Meta confirming that these were deliberate and intentional changes. He says, “This is not an accident: this concern was reported to Meta early in 2024 via official means in the Khronos group. Meta acknowledged purposedly blocking other platforms from running OpenXR content at that time.” I was able to confirm in my discussion with Guy Godwin in this Voices of VR podcast episode that he also believes that these were deliberate and intentional changes to undermine the spirit of OpenXR.
Part of why Bucchianeri was blowing the whistle is because the Khronos Group had not been taking any action against Meta. He describes Meta’s actions as “reverting many of the improvements to the developers and users ecosystem that Khronos has spent time, money, energy into solving for the past 7 years.” He says, “Unfortunately, since 2024, Khronos has refused to take actions to stop Meta’s OVRPlugin destructive initiative towards the PCVR ecosystem. By not taking any actions to resolve the issues created by Meta’s OVRPlugin, Khronos is sending the message that OpenXR is no longer a universal solution for cross-vendor and cross-platform support, that passing the CTS [OpenXR Conformance Test Suite] and being conformant mean nothing (conformant runtimes are precluded from running OpenXR apps), and that the OpenXR logo and trademark no longer carry the same significance as before in the PCVR ecosystem.”
Bucchianeri was not happy with the lack of a public response from The Khronos Group, and on the evening of February 8th, 2025 he posted a GitHub issue requesting to the OpenXR-Docs to “Please remove my name from the specification and public documents.” He spoke publicly about this issue for the first time by saying, “Khronos was once an organization that worked relentlessly to make OpenXR a cross-vendor, cross-platform standard of high quality. Unfortunately, since 2024, Khronos has refused to take actions to stop Meta’s OVRPlugin destructive initiative towards the PCVR ecosystem… I do not wish to see my name – Matthieu Bucchianeri, an independent developer – associated with an organization that has turned its back on developers, that promotes discrimination against small vendors/developers and that encourages practices that go against the foundations of the original OpenXR brand.”
Bucchianeri also posted an issue to the OpenXR-Inventory to remove his OpenXR products from the Khronos repository saying, “To protest against Khronos complacency and failure to take action to end Meta’s attacks to minority vendors, small developers and against the PCVR ecosystem through their OVRPlugin.” He updated his initial GitHub post on February 11th after he had posted his more detailed technical breakdown by saying, “For an overview of how OVRPlugin has been violating the OpenXR best practices since 2023 – see this technical description.”
After nearly two weeks, the Khronos Group felt enough pressure from the OpenXR community about this issue that they issued a rare public statement on February 21, 2025 titled “Statement from OpenXR Working Group in Response to Community Discourse on the OVRPlugin from Meta.” But this title was the only explicit mention of Meta, and it is a bit of an ambiguous statement that does not appear to directly address the issue. They say, “The Khronos OpenXR Working Group recognizes the challenges developers have faced with legacy APIs and platform-specific behaviors that limit XR application portability. The Working Group is dedicated to evolving OpenXR by incorporating vendor extensions into the core specification and continues to enhance platform interoperability. Today, three major engines – Unity, Unreal, and Godot – support building OpenXR applications that are compatible with multiple vendors’ OpenXR conformant devices, provided vendor-specific features are avoided.”
The Khronos Group seems to be saying that if you want an OpenXR middleware solution that is “compatible with multiple vendors’ OpenXR conformant devices,” then check out the OpenXR plug-ins from either Unity, Unreal, and Godot. The implications of Khronos’s statement responding to “community discourse on the OVRPlugin from Meta” is to simply not use Meta’s plug-in. But Bucchianeri is also claiming that Meta is going out of their way to discourage users from using any other OpenXR plug-in aside from their own by giving a variety of different scary warning messages. He says, “Meta has crafted a user experience in the game engines that forces developers to select OVRPlugin while making it difficult to implement fallbacks to standard OpenXR support. In Unity for example, a developer selecting OpenXR support after having enabled OVRPlugin will be prompted with a message declaring “incompatibility” and reverting the selection of plugin to OVRPlugin exclusively.”
I was sent the specific warning message from a VR developer when they tried to use Unity’s OpenXR Plugin. “This APK includes libUnityOpenXR.so, but not libOVRPlugin.so. The Unity native OpenXR plugin is not yet fully production ready. If you are experiencing performance or compatibility issues, please enable the Oculus XR plugin (and disable the OpenXR plugin) in your project.” You can find this specific warning message shared in a forum here in May 2024, and an earlier version of this message from March 2024 that says, “Unity’s OpenXR plugin is not recommended when using Oculus SDK, please use Oculus XR Plug-in instead.”
I spoke with Virtual Desktop’s Guy Godin about all of this in this episode of the Voices of VR podcast (see full transcript below), and he identified Meta’s Integration SDK v51 released on April 25, 2023 as “when games started to no longer be compatible and break when played with Virtual Desktop.”
I reached out to Meta on Wednesday afternoon to see if they had any public comment about any of these OpenXR controversies, but they have not replied to my inquiry at the time of publication. If Meta does decide to make a public statement, then I’ll add it as an update. The last public statement from Meta about OpenXR that I could find was from the press release of OpenXR 1.1 on April 15, 2024 where Meta was quoted as saying, “Meta has been committed to building an open, cross-platform standard for the XR industry since the inception of the OpenXR standard in 2016”, says Jonathan Wright, senior staff engineer at Meta. “The OpenXR 1.1 release is one more step towards making it easier for developers to build XR applications. We continue to support the evolution of the OpenXR standard as we work to build an open and interoperable XR ecosystem.”
Even though Meta was publicly supporting OpenXR as late as April 2024, according to Godin’s and Bucchianeri’s allegations Meta may have already been starting to undermine the spirit of OpenXR for a year going back as early of April 2023. The public statement from Khronos Group acknowledges the controversy from community about Meta’s OVRPlugin, and suggests using the game engine plug-ins if you’re looking for a OpenXR plug-in that is “compatible with multiple vendors’ OpenXR conformant devices.” It is difficult to independently confirm when exactly Meta’s shift away from supporting the spirit of OpenXR may have happened, but there seems to be a distinct shift from the Meta’s last public statements on April 15, 2024 and even earlier in 2023 according to the public allegations from Godin and Bucchianeri. For more details and context, then be sure to check out the full transcript with my conversation with Godin below.
UPDATE: March 7, 2024.
Meta posted a developer blog about “Meta and OpenXR” today where they say, “Starting with our v74 SDK, available next week, the built-in OpenXR path for all major game engines will be a recommended path for development. Developers building on Unity, Unreal and Godot can leverage OpenXR to build across platforms and access Meta platform plugins to add features unique to Horizon OS.”
They also provided the following statement about their commitment to OpenXR.
“Advancing the OpenXR Standard
“Since ensuring that our OpenXR runtimes for Meta Quest and PC were 100% OpenXR compliant in 2019, we have pushed to continue advancing OpenXR as a viable cross-device solution. We are continuously creating new XR technologies to enable unique and immersive experiences, exposed as OpenXR extensions. We also build libraries to support these new extensions. As part of our commitment to OpenXR, we contribute these advancements back to the community, allowing other companies to adopt and build upon them.
“In fact, Meta has contributed to 33 (~67%) of Khronos and cross-vendor extensions, as well as 61 vendor-specific extensions. Among those vendor-specific extensions, many of them (e.g. SpaceWarp, foveation, passthrough, etc.) are adopted by other OpenXR vendors for the better interoperability with apps that were originally developed for Meta devices. These contributions have been adopted by other vendors who recognize Meta’s dedication to advancing the industry and contributing back to the standard.
“Meta’s Commitment to OpenXR
“As early adopters of OpenXR, Meta has contributed significant resources to both expanding the standard and enabling OpenXR support in popular game engines. We remain committed to OpenXR and will continue to invest in the success of OpenXR and our developers.”
Meta’s Chris Pruett also responded on X saying in conclusion that “The idea that we’re trying to undermine OpenXR ignores our significant, multi-year push to create the spec, support Khronos, and move all of our runtimes to this open standard. Our position continues to be that developer success across platforms is a tide that lifts all boats.”
Full thread is here.
Also UploadVR’s David Heaney also reported on the Meta / OpenXR story will a follow up here. He says in the comments, “Seems like the issue here stemmed more from a long strategy execution time, typical of a big tech company, rather than some machiavellian scheme to undermine OpenXR.”
This is a listener-supported podcast through the Voices of VR Patreon.
Music: Fatality
Podcast: Play in new window | Download
Rough Transcript
[00:00:05.458] Kent Bye: The Voices of VR Podcast. Hello, my name is Kent Bye, and welcome to the Voices of VR Podcast. It's a podcast about the structures and forms of immersive storytelling and the future of spatial computing. You can support the podcast at patreon.com slash voicesofvr. So in today's episode, we're going to be unpacking a lot of the allegations that are currently being made against meta that they're undermining the spirit of OpenXR. So going back to February 8th and 11th, Matthew Buccianeri is an open source developer who started to make a series of different allegations that Meta was undermining the spirit of OpenXR. So what he's claiming is that if you use Meta's OVR plugin in You are launching, let's say, a cross-platform application on both the Quest native platform, but also PC VR. If you use everything on the Quest, everything's fine. There's no issues. But if you want to create a PCR version of that and you use Meta's OVR plugin, then there's gonna be some checks that will only make it so that only people with Quest headsets or Quest Link could have access to your PC VR build. which goes against the whole idea of what OpenXR is supposed to be, which is you build these OpenXR integrations and it's supposed to work across all these different platforms. So what I think is happening here is that there's OpenXR conformance and the conformance only applies to the runtime. So that means that the hardware that's on the device, it's conformant if it's able to speak to any APIs and get access to all that hardware data. But there's the plugins that are not necessarily under that same open XR conformance. There's only like normative standards and best practices that Kronos Group says that you should follow in order to live into the spirit of what open XR is trying to do with this cross-platform cross-compatible. And so that's where Meta has started to undermine the spirit of OpenXR is in their own OVR plugin, their own integrations. And they've stopped living into the spirit of OpenXR. Sometime, according to both Bukuneri and Guy Goudin, who is the author of Virtual Desktop, and Guy and Matthew had collaborated on building a virtual desktop OpenXR integration program. And so Virtual Desktop, for anyone who doesn't know, it's like a middleware solution so that you could, through all these OpenXR APIs, to get access to all the different PC VR programs. And so you started to see a lot of these incompatibility issues starting around like April or May of 2023, which was the release of Oculus's integration SDK version 51 that came out on April 23rd, 2023. And so in that May of 2023, Guy started reaching out to Meta saying, hey, you know, all this compatibility is broken. There's all these special checks, you know, it's looking for these headsets. And Guy told me in this interview that we'll be diving into that Meta just told him, oh, there's some specific ways to bypass it, just kind of pass that variable over. But that, again, goes against the whole spirit of what OpenXR is supposed to do, which is like this cross-compatible open standard approach. There was all this controversy for a couple weeks, and then Chronos Group actually came out and made a statement. And their statement was essentially like a non-statement. And they said there's a statement from the working group in response to the community discourse on OVR plugin for Meta. And Chronos Group essentially says, if you want to use a plugin that's, quote, compatible with multiple vendors' OpenXR-conformant devices, then just use one of the game engine's OpenXR plugins, either from Unity, Unreal, or Godot. And then as we go into in this conversation, then Meta has all these ways that they're pushing back and really suggesting the developers that they really should use their plugin and not all these other plugins. And so it's kind of gotten to the point where OpenXR was supposed to simplify a lot of things. But now that Meta has started to undermine OpenXR, it's actually made it even worse than it was before. Yeah. Anyway, these are a lot of the allegations. I reached out to Meta to see if they had any comment. They haven't replied to my email. They might, and if there is any update, if they do make a public statement, then I'll go ahead and include it in the description. But as of this point, they haven't made any public comment about this at all. So... Hopefully this is all one big misunderstanding. They'll be able to go back and correct this and change it. But according to both Guy and Matthew, this is a deliberate action that they have internal communications from Meta saying that this was a deliberate action and they're not going to change it. So we'll be covering all that and more on today's episode of the Voices of VR podcast. So this interview with Guy happened on Tuesday, February 25th, 2025. So with that, let's go ahead and dive right in.
[00:04:30.243] Guy Godin: Hi, my name is Guy Godin. I'm the developer of Virtual Desktop, which is a very well-known app in the VR scene. It lets you connect to your computer and stream your desktop, stream games, VR games, PC VR games, videos, and a bunch of other things.
[00:04:46.271] Kent Bye: OK. And yeah, maybe you could just give a bit more context as to your background and your journey into the space.
[00:04:52.430] Guy Godin: Yes. So I worked in the game industry for 15 years before I jumped into VR just for fun as a side project. So that was in 2014. I ordered an Oculus DK2. I was curious about the space and I started playing with the SDKs and all that. When I put on the headset, the thing I was missing was the computer. So I was like, it's connected with an HDMI cable to the computer. Why can't So I started working on an app just for fun, just to learn how could I stream or see my computer screen while I wear the Vihar headset. And it turned out it was kind of a useful tool to have and lots of people enjoyed it. So I shared my app for free on Oculus Share at the time. And then I released my app on Steam in 2016 when the first Oculus Rift HTC Vive headsets came out and it became quite popular. So I decided to switch to full-time in 2017. That's what I've been doing since then.
[00:05:50.172] Kent Bye: We're catching up today because there's been a little bit of a dust up over Meta's OVR plugin in terms of it used to have OpenXR compliance as I was going through and looking at a website that shows which devices are conformant to OpenXR standards. So back in July 25th, 2020, Oculus had the Android be compliant to the OpenXR standards. And then after that, there was on August 21st, there was Oculus PC runtime, which was conformant with Windows 10 and then also the Rift S. And then the Oculus Quest 2 was conformant on October 15th, 2020. And then if we skip forward, the next time that we have updates to this conformance list, is in 2023, so this is after the name change from Facebook to Meta, so you have a reestablishment of what's conformant. The Quest 2, 3, and Pro, that's all conformant to Android. And what ends up happening is that the Oculus PC runtime gets dropped at this point. Meta is no longer going for OpenXR compliance for their PC runtime. They do the MetaXR simulator, which was on October 11th, 2023. But at this point, there's no longer any listed conformant PC runtime. as of October 11th, 2023. There's a switch that happens. Meta at some point decides to not fully support OpenXR. So maybe you could just give a little bit more context from your perspective as to when you first started to notice some of these shifts and changes.
[00:07:31.382] Guy Godin: Right. So yeah, in early 2020, Meta wanted to move away at least on the mobile side from VR API. to OpenXR, which is an open standard. So, I mean, it was a good thing. You know, I was very happy about that because the idea is that instead of having to write your app against different SDKs for each platform, now the goal is that you could write your app against one API and that way you looks across all the various headsets. That was the goal, at least. What happened, actually, is that Meta decided to make their SDK that they pushed developers to use to only work with Quest headsets and only with their software solution, which is Air Link. So if you want to make a VR game today and you look at the documentation and all that, and you go, oh, there's the meta XR SDK. It uses open XR. Great. I'll use that and I'll make my game. Problem is that if you don't really test on other headsets until you're done with your game, you'll realize that it only works with quests and nothing else. So we're back exactly to where we were before, where you need to use different SDK if you want to target different headsets. So The whole OpenXR slogan and hooray was all bullshit, essentially. They're promoting it as if they're using open standards, but their own SDK doesn't respect the goal of OpenXR.
[00:09:09.164] Kent Bye: Okay, so is this something that you ran into with a virtual desktop or maybe just kind of like detail? How did you first come across this issue?
[00:09:17.765] Guy Godin: Well, in my case, I'm shielded from that because I don't use Unity or Unreal. So I'm a native developer. So I program directly against OpenXR. So I don't have this issue. But the number of developers who use the native approach is like 1% or even less than 1%. Nobody develops natively, or at least nobody that has stuff on the stores use the native OpenXR SDK. So I was kind of shielded from that and I didn't really notice that until some games started to appear in 2021, I think, or 2022. PC VR games released on Steam. And then they had all these weird issues where the hands were not positioned correctly or the game refused to work. And we've seen all these compatibility issues with games that were kind of surprising. And then it turns out we figured out that, well, metas sdk at some point they stopped supporting other headsets and they essentially put a hard-coded check that if you're not using the metal runtime just fail say you have to use the metal runtime and so they put hard checks into their sdk to prevent from working on any other headset or any other solution so i've had to implement and i work with matt Matt is an open source guy who created an OpenXR runtime for a virtual desktop. He put that on a GitHub and it's open source. And we've had so much pain and trouble to get games to work correctly because of those limitations that Meta put into their SDK.
[00:10:46.659] Kent Bye: So maybe you just explain a little bit like who Matt is and how he's collaborating and working with you on virtual desktop.
[00:10:53.377] Guy Godin: Right. So Matt approached me a few years ago and he said, I'm part of the OpenXR group and I've made an OpenXR runtime for Pimax. And since the Pimax API is essentially a carbon copy of the Oculus runtime API, which is what I've replicated as well in virtual desktop, he said, I could make an OpenXR runtime for virtual desktop. Would you be interested? And I was like, oh yeah that'd be super cool and he develops a lot of open source stuff and he had experience in the past with playstation vr and you know he was working at microsoft back then on some other xr stuff and he offered to do that i was like sure i'd be happy to you know help you and work with you to bring that so we worked for a couple months and we integrated that into virtual desktop which is what we call now vdxr And we offer the choice for users. They can either run their games against the SteamVR OpenXR runtime or the virtual desktop OpenXR runtime that Mac created. So it's been a few years now that we've had it in the app. And people love it because it performs really well, performs better than all the other options. And we forward all the face tracking, eye tracking like the Quest Pro has or the body tracking now that the Quest headsets have. So we forward all that to the PC so that games like VRChat and other games can actually use those extensions. Because those extensions, they were never brought over by Meta to the PC side. They only let you use it as a developer, but they don't expose it so games can use it. So we made it available so that people that have quests that have face tracking, eye tracking, body tracking, all that, so that PC VR developers can use those.
[00:12:34.252] Kent Bye: Okay, so in the post that Matt had written up on his GitHub that was talking about Meta's OVR plugin, he links to a post that was called XR Plugin Management from MetaQuest. It was updated July 11th, 2024. So I don't know if that's around the time. It was around mid-2024? When were you first starting to see some of these different issues being reported? Because it sounds like that because virtual desktop is kind of like middleware, You're interfacing with a lot of these other applications and I guess kind of running into some of these issues. And so when did you first started to hear some about what was happening?
[00:13:10.314] Guy Godin: I think it was in 2023 that their SDK, I think this was version V 51 or something that the shenanigans started. I mean, it's, it hasn't been smooth at all since the introduction of open XR, which was supposed to make all of this easier for all of us. it just made things worse. Because instead of having the Oculus API and the OpenVR API, now we had a third one, which is OpenXR. But it depends which OpenXR. Is it the games using the meta plugin, or is it using the Unity plugin? So now we kind of have like four or five different flavors of having VR games. And the way you run it, the way input works is all broken, depending on which bucket you fall into.
[00:13:56.218] Kent Bye: Okay, and in this post that Matt had written up, he says that they started to run into all these different issues, including Meta's OVR plugin breaks the contract and assumptions built by OpenXR. He says, a developer using an OpenXR middleware expects cross-platform, cross-vendor compatibility. Meta's OVR plugin prevents this from happening. Meta has no incentive to solve this problem since the content will continue to work on their platform. A platform, vendors, or runtime developer implementing the OpenXR standard and seeking and paying for OpenXR conformance expects OpenXR content to work on their platform. Meta's OVR plugin is defining their own conformance and undermining the efforts of all other vendors and industry who have proudly earned the OpenXR logo for their products. OpenXR conformance contractors and contributors are implementing a test suite to help vendors create high-quality runtimes. Meta and their OVR plugin is discrediting their work and making competitors' OpenXR implementation look incompatible of running OpenXR content while presenting their OpenXR runtime as the only adequate solution. And he continues by saying, this is not an accident. This concern was reported to Meta in early 2024 via official means and the Khronos group Meta acknowledged purposely blocking other platforms from running OpenXR content at that time. And so when these discussions were happening, did you hear around that Meta acknowledged blocking other platforms? So when did you hear this for the back channels that Meta was deliberately doing some of this stuff?
[00:15:27.942] Guy Godin: Well, I think it was in 2023 because there was one version of their SDK that started blocking other headsets, version V51 or something. And I reported that to Meta and I emailed them and I'm like, Why is this happening? Why are you not supporting OpenXR? And all that. And then they emailed me, oh, you can trick it by using an API layer and making it think that you're running a meta. Like some crazy, crazy steps essentially to bypass the whole thing. But then there were also other compatibility issues. So I reached out to Meta 2023 about this issue because some games were starting to come out that no longer worked. And so it's been a few years that it's been ongoing. And the sad part is that for Meta to fix this would take a week of work. Like they purposefully spent more time blocking things than it would for them to make their SDK be cross-platform like OpenXR and Danza 2. Right. So if they just spent a week on that, and then every time they push an SDK update, they make sure to test with other headsets and other runtimes as a bit, a few hours every month. Right. But that's it. They're a trillion dollar company. There's no excuse. They should be able to do that and make an SDK that's cross-platform as it is intended to be.
[00:16:50.234] Kent Bye: Hmm. Yeah, so there's been some rumblings after Matt had posted this and started spreading it around. I heard it through some back channels where some of this discussion was starting to happen. So on February 11th, I first heard about it. I'm not sure if that was very soon after Matt had posted it and started getting the word out. At what point did he come to you saying that he wanted to go public for what was happening behind the scenes with Meta?
[00:17:16.671] Guy Godin: I had no idea. One day he said, I'm really sick of this, and so I posted this, and that's the thing we saw a few weeks ago where he wants his name removed from the OpenXR documentation because he doesn't want to be associated with it, which I understand. He must be frustrated because you spend years working with OpenStandard when in the end the Kronos group, which is supposed to promote that, ends up just giving up and letting Meta do whatever they want.
[00:17:46.127] Kent Bye: Yeah, so that was on February 8th, 2025. There was a GitHub for Kronos Group, issue number 182. It says, please remove my name from specification and public documents and goes through all the different places where he wants to be completely disassociated from anything to do with OpenXR. And in his letter at the bottom, It sounds like there's this back and forth getting Meta saying that they're deliberately undermining different aspects of the OpenXR, which are happening in these private back channels. Did you see any evidence that Meta had said that they were deliberately doing that?
[00:18:18.527] Guy Godin: Well, I mean, I can't because I'm under NDA with Meta, so I can't really talk about my exchanges with them. But basically, when I talk with them, they're well aware that that's what they're doing, and I complain to them, and they refuse to do anything, so...
[00:18:32.389] Kent Bye: Okay, and Matt's also saying the same thing, that there's these back and forths where they're trying to get Meta to do something, they're not doing it. And so at the bottom of this post, Matt says, unfortunately, since 2024, Kronos has refused to take actions to stop Meta's OVR plugin destructive initiative towards the PCR VR ecosystem. By not taking any actions to resolve the issues created by Meta's OVR plugin, Kronos is sending the message that OpenXR is no longer a universal solution for cross-vendor and cross-platform support. that the passing the CTS, which is the OpenXR conformance, and being conformant mean nothing. Conformant runtimes are precluded from running OpenXR apps. And the OpenXR logo and trademark no longer carry the same significance as before in the PC VR ecosystem. So there seems to be like this public campaign where Matt's bringing attention to this and advocating for other developers to start to reach out. And we'll sort of get to what Kronos Group has to say in response to that, but I'll have you jump in and give any from your perspective of like this initial pushback for Kronos Group to say something.
[00:19:37.544] Guy Godin: Right. I think I did a tweet about the whole thing a few years back. I'd have to go back to Planet, but Yeah, I'm not part of the OpenXR consortium, right? I'm not a member. I remember when they initially pushed it, some people approached me, maybe you would be interested. I said, yeah, I'd be interested, but I never heard back. So I was not part of the consortium and all that. But I'd probably be in the same boat as Matt. If I saw that, I would probably have complained and nothing would have happened, right? Because Matt actually worked on a lot of OpenXR stuff. He spent years working with them. So I totally understand his position. He's frustrated because Meta is going against the ethos, the mission of OpenXR, which is to make everything work on any headset.
[00:20:20.359] Kent Bye: And so when I see the statement from OpenXR, it sounds like a bit of a non-statement. I'm going to read the statement in full because I'm trying to parse exactly what they're saying. So the context here is that Matt makes this post. There's a big outrage from the developer community saying, hey, it looks like meta may in fact be undermining certain aspects of OpenXR. So then the Chronos group makes a statement. This is their statement. They say, And this is on February 21st, 2025. This is last Friday. So first of all, that's the only thing that they even mention anything about, that there's a community discourse, there's people who are upset, and it involves meta. But from this point on, there's no mention of meta. It says... The Khronos OpenXR Working Group recognizes the challenges developers have faced with legacy APIs and platform-specific behaviors that limit XR application portability. The Working Group is dedicated to evolving OpenXR by incorporating vendor extensions into the core specification and continues to enhance platform interoperability. Today, three major engines, Unity, Unreal, and Godot, support building OpenXR applications that are compatible with multiple vendors' OpenXR-conformant devices, provided vendor-specific features are avoided. Application developers retain the choice to target specific runtimes and devices if desired, though this approach may introduce some vendor dependencies. For guidance on building OpenXR PC VR applications on Windows without vendor dependencies, then there's three links that link to both Unity, Unreal, and Godot. When I read this, it doesn't sound like they're addressing it at all.
[00:21:56.514] Guy Godin: No, they're skirting the problem. They're just saying, oh, well, don't use their SDK if you want to target everybody. Well, the issue is that the SDK could very well work against all headset if Meta just did it correctly according to the mission. I mean, I'm doing it with my app. I have one app. One APK works across three platforms, no problem. But that's because I don't use any of the meta SDK. And developers today, if they're on Unity, if they use the Unity OpenXR plugin... It will work across all headsets, no problem. It's just that the Meta's SDK, the one that they push you to use, because they bundle all the stuff with it and all that. And if you use that, then you're not going to work on any other headset. So yeah, OpenXR is just saying, oh, it's the developer's fault. They're not using the right SDK. But developers are just going to Google things, see, oh, Meta has an OpenXR SDK. I'll use that and not realize a few months later when They've made so much progress that their thing doesn't work on any other headset.
[00:22:58.056] Kent Bye: So it sounds like the Kronos Group response to this controversy is a lot of people are complaining that Meta's OVR plugin is not OpenXR conformant. And their solution is to say, just use one of these other three game engine OpenXR implementations, essentially. Right.
[00:23:15.899] Guy Godin: But they're allowed to call it an OpenXR SDK, even though it doesn't respect the logic of it. So, eh.
[00:23:22.557] Kent Bye: Well, here's what I found in looking into it is that from the first time that Meta got the OpenXR conformance, that was back in 2020. They had conformance for the Oculus PC runtime, but then when they rebranded into Meta, they never re-upped the OpenXR PC runtime. Everything that is conformant is on Android. So even though they're conformant on Android, they don't have any claims that they're trying to be conformant for PC VR. So I don't know if that's how they're able to kind of like because they are, let's say, compliant to like their Android runtime specification. When I read it, that's what I see might be happening, is that they kind of subtly never got conformance for their PC runtime because they're abandoning PC VR, essentially. They don't currently have a runtime that's conformant on the PC on Windows. The last time that was back in 2020, the only thing that is listed on Windows on the conformance page is the MetaXR simulator. which is different than the actual runtime. So it sounds like that Meta has abandoned their runtime for the PC, as far as I can tell.
[00:24:34.029] Guy Godin: Yeah, I mean, I think there's just like some sneaky legal way to not do the right thing. I don't know. I find this whole situation kind of sad since Meta has been pushing the industry and now they're essentially killing it with all their bad decisions.
[00:24:55.336] Kent Bye: Well, I heard from another developer who sent me this little passage of an error message that happens when you try to use the OpenXR from Unity, you get an error that says, this APK includes libunityopenxr.so, but not libovrplugin.so. The Unity native OpenXR plugin is not yet fully production ready. If you are experiencing performance or compatibility issues, please enable the OpenXR plugin and disable the OpenXR plugin in your project. So essentially, if you try to use the Unity, you're going to get these error messages that say, look, it's not production ready. You should use ours instead.
[00:25:32.560] Guy Godin: Yeah, they do everything to push you to not use the Unity or the other ones. They want you to use their plugin. They're like, oh, if you want to use body tracking, you want to use a special SDK or, you know, and they make it so tempting for developers to just use their SDK because, well, everything's falling into it. The help says to use it. All their documentation says to use it. Like, it's just trapping developers into using their, GSDK, I'm really frustrated. As you can see, it's just so annoying. I'm kind of used to this. It's been, I've been working in VR for 10 years and it's been the theme.
[00:26:10.475] Kent Bye: And so just to flesh this out a little bit more, just to get a little bit sense of how this is impacting you as a developer, because let's say someone uses the OVR plugin. What are some of the different feedback or messages you get from virtual desktop because it's not a proper OpenXR implementation?
[00:26:28.720] Guy Godin: What happens is that the games typically like you take a game that goes off the bar, right? They're both a mobile and PC VR game. And I think it was last year when they released their game, they used the meta plugin, the unreal one. And so their game works on Quest, no issues. Then when it comes to PC VR, on my side in virtual desktop so that they can play, I have to tweak virtual desktop because it uses the OVR plugin. And then we've had to figure out all those dependency issues. And then the hand positions are not right. Things don't work correctly. So the game launches and usually game developers don't test against virtual desktop. They just test against Thinker because they think, well, that's the official way to stream pcvr games i'll just make sure that works and that's it but in reality the majority of people use virtual desktop the gamers who game every week they use my app so often i'll have to do some patches quick patches to fix issues and to fix compatibility either by placing the game in a bucket or another or tweaking something in the runtime to make it work and i have to have a dialogue with developers and developers always like Isn't it OpenXR? Shouldn't it work? Why do I have to do all this? Why do I have to do something specific to a virtual desktop when it works with Link and Air Link? And now there's Steam, which has Steam Link, which essentially have the same issues as we have, where if a developer uses the OVR plugin, then it messes with compatibility. Steam's way of handling that is adding like a meta compatible D option. Then you have the on automatic or off option. And then you have to check that for a game that uses the over your plugin. Anyway, it's, it's a fricking nightmare, right? The whole point of open XR was that you write your game once against one API networks across the board, but we're not there at all. Like it's not even close. It's worse than it was a few years ago. So. Yeah, so every time a game launches, I get complaints from developers that say, oh, why is my game not working with virtual desktop and all that? And most of the time, it's an OVR plugin issue. So yeah. So that's been my life for the last few years is that hearing complaints from developers and then trying to get things working to work around the various things that meta did. Yeah.
[00:28:40.768] Kent Bye: Okay, so quick question on just the Ghosts of Tabor, just to clarify. So it sounds like that there's a PC and Android version. They're using the OVR plugin in both. It seems to work fine on a Quest headset. What happens if they have it on PC?
[00:28:56.497] Guy Godin: On a Quest with Link or Air Link only.
[00:28:59.499] Kent Bye: Okay, okay. So if they use Quest with Link or Air Link, it'll work fine. But if they try to use the virtual desktop...
[00:29:08.328] Guy Godin: Things don't work. So what happened is that when working with the Ghosts of Sabor folks, what they ended up having to do, because it was just a nightmare, they had to change their game on Steam to actually use the old OpenVR. So right now their game on Steam uses OpenVR, the old OpenVR, to avoid all this compatibility nightmare. And on Quest, they use OpenXR and their plugin and all that. But for the PC version of their app, now they're using OpenVR.
[00:29:38.629] Kent Bye: Do you think that this is just incompetence or is this a deliberate strategy that's happening?
[00:29:43.512] Guy Godin: No, it's deliberate. I'm way past the incompetence at that point because it's stupid.
[00:29:50.595] Kent Bye: Is Meta just trying to own the ecosystem or what do you think is happening? Why are they doing this?
[00:29:55.938] Guy Godin: They're just trying to own everything. They don't care about me. They don't care about the developers who are struggling to make things work. They're just trying to own everything. And it's backfiring because they're killing their industry.
[00:30:07.662] Kent Bye: Yeah, there was a memo that Mark Zuckerberg had written that was basically laying out their strategy and that they were going to be focusing on first-party apps, first priority, second priority, software and services, and third priority, the hardware. And it seems like that they've been taking that approach over time. So it seems like that OpenXR would be something that would ideally allow them just to write things once. The thing I'm trying to get at in some ways is if the Android implementation of OpenXR, if there is no longer compliance with their plugin, even on the Android. So I know that they no longer have a PC runtime, but even within their implementation within the OVR plugin for the Quest, it sounds like they're no longer in conformance. Is that true?
[00:30:54.628] Guy Godin: Well, the thing is, I'm not sure what exactly conformance means. If it just means that you use the APIs and that your runtime can work. I think the conformance is only on the runtime side, not the SDK, right? So I have a feeling that they can... I don't know right now if you use their SDK, if you can have your app work on Pico. I believe not. Like I could be wrong, but I'm not sure cause I haven't tried their, uh, unreal or unity plugin recently, but I have a feeling it's the same issue where it doesn't work on the other headsets. Maybe it does. I have no idea, but yeah, it's really stupid that developers have to jump through hoops like that.
[00:31:32.653] Kent Bye: So it sounds like the ideal of having like an open XR compatible plugin is that you would make a build for quest and then use that same exact build for the Pico headset. And what you're saying is that if you use OVR plugin, it's not going to work.
[00:31:44.784] Guy Godin: I have a feeling that this is how it is today. I could be wrong, though. Don't quote me on that. I just know that for the PC VR part, it doesn't work if you're not using Link or iLink.
[00:31:54.747] Kent Bye: What do you suggest that developers do to get around some of these different things?
[00:31:58.789] Guy Godin: Well, I'm trying to push developers to not use the OVR plugin, but the problem is, like you said, they see messages saying that they're not going to have the same performance. They're missing features, like if you want to have body tracking, if you want to have hand-tracking some specific stuff with their spatial SDK, or if you want to use an app space warp that they added recently on Quest. If you want to use all these advanced features, you have to use their SDK. Or the other option is to go native, but it's way too much for most developers to do that. So yeah, I mean, I would tell them to try to not use the meta SDK if you can, but I know most will end up using it.
[00:32:42.222] Kent Bye: Right. Gotcha. Okay, well, thanks for taking the time to sort of catch me up on all this stuff. I'm wondering, you know, as you are moving forward, what are some of the things that you're working on? I know that, you know, with Apple Vision Pro is coming out and that's something you're still working on or what's coming next for a virtual desktop?
[00:32:59.771] Guy Godin: Well, I can't say too much because people like to copy what I do, including meta. So I will not reveal future projects. But yeah, I'm working on some interesting things. Yeah, the Apple headset is a bit of a challenge for me because since I developed natively, the tools that I'm using the engine that I'm using and all that, none of that works on the Apple ecosystem. They don't use OpenXR. They don't support OpenGL. It's only metal. Everything's proprietary with Apple. So I'd have to essentially write my app from scratch in a different language on a different operating system using different SDKs that I've never used before. So I've started a little bit, but it's going to be a long way to get to a working app.
[00:33:45.279] Kent Bye: Okay. Yeah, I know that there's been a number of different intermediary solutions, ALVR and other stuff that's out there. But is that something that you still are planning to do just to kind of be a part of that ecosystem?
[00:33:56.016] Guy Godin: Well, we'll see. I mean, I'm working on it slowly. It's just a lower priority. So I have other things that I'm working on right now. So I'll see how the market evolves. Because right now, very few people have a Vision Pro. It's like a few hundred thousand people. So it's a very, very small market. So for now, if I was just looking at it on a business and time standpoint, it doesn't make a whole lot of sense to jump in. Although there are rumors that they're going to have a lower price headset in the future. So there's also the issue that They don't have controllers. So most games, and people essentially use my app mostly to stream PC VR games, it's really hard without controllers. Even if they're third-party ones, how many of the people who own the headset are going to buy third-party controllers? So yeah.
[00:34:44.690] Kent Bye: Nice. So in the process of trying to report on the story, not a lot of people that actually want to talk about this issue that's happening with Kronos and Meta on the record. Can you just speak to that? Why is it that you want to put yourself out there and speak about it? And what's the larger context for why other developers are not willing to speak about this?
[00:35:05.409] Guy Godin: Well, I'm not employed by anyone. I work for myself. So it's my own business and I sell my app and I You know, nobody can stop me from speaking out. Whereas I feel bad for other people, other developers, they have a relationship with Meta. Yes, I'm selling my app on their store, but they hate me anyway. So, you know, it's been that case forever. So I don't care at this point, but you know, developers that have a working relationship with them that are trying to get promoted or have their business work with Meta for publishing or, you know, thing is you can't really speak against them because they're the giant, right? So everything goes through them. So I kind of feel bad that other, the uppers can't really speak out. If they speak out, there'll be repercussions. And so.
[00:35:51.448] Kent Bye: Well, I'm glad that both Matt put out this public post and that you're willing to speak about it because, you know, I think it's an important issue. And it rose to the point where there's at least some confirmation where the Kronos group is implicitly saying, look, we know that there's an issue. Just don't use Meta's SDK. That's their recommendation from their post. So it feels like not really a bold statement. I think they're trying to play the Switzerland, you know, try to be in the middle, but they're There seems to be larger issues here where there may be, like I said earlier, they don't currently have a PC conformant runtime. And so I don't know if that's how they're able to get around some of this. But if you're using the OVR plugin on different hardware, but I don't know if they're even still claiming that that's a part of like an open XR compliance. I think what they're saying is that conformance is only isolated.
[00:36:41.199] Guy Godin: The runtime side. Yeah. I think it's just the runtime side. Yeah. Which has conformance or not. So SDK, you can do whatever fuckery you want, and you can get away with it. That's probably why Meta did this, because they can't get away with it, and Kronos can't do anything about it.
[00:36:57.773] Kent Bye: Right, so they may be still technically in compliance, but it just seems like the spirit of it, like having these ways of purposely blocking other headsets, that just seems wrong.
[00:37:08.303] Guy Godin: It totally is.
[00:37:11.167] Kent Bye: So awesome. Well, Guy, thanks so much for joining me here on the podcast to help break some of this down. And yeah, we'll put this out there and see if anything changes. So thanks for being willing to be out there and speak out about all this.
[00:37:22.296] Guy Godin: Yeah, thanks for reaching out.
[00:37:24.778] Kent Bye: So that was Guy Gouin. He's the developer of Virtual Desktop. So I have a number of different takeaways about this interview is that, first of all, Well, to me, it seems pretty damning about what Meta is doing. They haven't made any public statement about this at all. There was all these allegations that were coming out from Matthew Bucaneri. Now with this interview with Geekwood and another developer who's going on the record, if there's any other developers that want to go on the record or speak about that, I'd recommend maybe following up with like UploadVR or Road to VR, I'm going to be going off to South by Southwest next week and I'll be a little bit busy. I'm not able to dig more into this story, but I did want to at least progress the story a little bit. Just try to capture what I see is happening. Try to look into the different timelines and when this might've happened, but also how to potentially independently confirm it. If people are using Meta's OVR plugin and you have like a build that's on the Quest version on Android, but also a PC VR version, then go ahead and see if it works and see if you're actually getting those blocks and see if you're able to implement some of the technical workarounds from those blocks to see if there are these workarounds that work. And you shouldn't have to do all these different workarounds. You shouldn't have to like go out of your way to make sure that you're creating an application that is cross compatible and have to jump through all these extra hoops. It sounds like Meta is integrating all these specific features and extensions that are only in their SDK. So it creates this incentive that if you want to use those, then you have to use their SDK, which is then trying to control and own the XR ecosystem, which why? I mean, to me, it's just going against the spirit of OpenXR. And they've been pulling back and their priorities are shifting. And we don't even know how strong their commitment to XR is in the long term, just because they seem to be very interested in AI and putting a lot of their eggs in the basket of Horizon Worlds. And They kind of abandoned PC VR a long time ago, so they're not really as concerned as to the needs or concerns of folks in the PC VR realm. And according to Guy, is that they're deliberately spending more engineering time working around these open standards rather than just implementing them. But it seems to be some decision internally, maybe sometime around like April or May of 2020. 2023 with the Oculus integration SDK version 51 is what Guy is identifying is when this started to happen. That's when he started to see some of these incompatibility checks be put into place. Matthew Bicaneri also says that 2023 that this was happening and that certainly that Kronos knew about it as long as like 2024 and that they weren't taking any specific action. And there probably isn't really a good enforcement mechanism within the context of Kronos Group. Kronos Group is supposed to be people collaborating and creating this. They're not like the enforcers of making sure that people actually follow it. The only thing that they can actually do with their conformance test suite with OpenXR is to see if the runtimes are conformant. And that's the thing that's actually on the hardware that makes the device available to other valid OpenXR implementations. And so they're not doing anything on that level. It's in their own SDK and software level, which doesn't seem to have any strict enforcement or requirements or regulation from Kronos Group. normative standards, best practices for how to create a more cross-compatible open and interoperable interfaces with open XR. And that to me, it's pretty damning that Kronos group put out the statement as much as it's a non-statement, they are actually saying, if you want to quote, support building OpenXR applications that are compatible with multiple vendors, OpenXR conformant devices, then, you know, they're saying use these three other OpenXR plugins from the game engines, from Unity, Unreal, and Godot, and that you'll be able to have your implementation and ship it cross-platform. And then, What other developers have sent to me is that there are these warning messages that are being sent that seem very scary saying this Unity plugin isn't production ready. And you know, all these ways of trying to pressure you to use their own plugin through these different warning messages and whatnot. So I reached out to Meta, like I said, I haven't heard back anything from them yet. They may make some sort of public statement. I hope they do. I hope they don't just like ignore this and hope it goes away. You know, it's the last public statement that I saw from Meta was actually for the OpenXR 1.1 release that was on YouTube. April 15th, 2024. And there was a quote in the press release from Meta that says, quote, Meta has been committed to building an open cross-platform standard for the XR industry since the inception of the OpenXR standard in 2016, says Jonathan Wright, senior staff engineer at Meta. The OpenXR 1.1 release is one more step towards making it easier for developers to build XR applications. We continue to support the evolution of the OpenXR standard as we work to build an open and interoperable XR ecosystem. So that was April 15th, 2024. And according to Guy, they started to subtly undermine the spirit of OpenXR as early as April 25th, 2023, with the release of version 51 of the Oculus integration SDK. That's when Guy said that he started to see some of these different issues. Matthew Bucaneri also said like 2023, but 2024 for sure, that this issue was brought to Kronos, even despite the 1.1 release and these public statements. So something clearly changed between April of 2023 or 2024 and February of 2025 because Meta is not saying anything at all. Kronos Group is speaking out, implicitly saying don't use Meta's plugin. And then you have all these public allegations that Meta has been undermining the OpenXR interoperability. So I did a whole write up with more details from Matthew's breakdown. And if I do hear back from Meta, I'll include a statement here at the bottom. and, you know, reach out and tell meta what you think about this. I think it's to me speaking to their short-term thinking, utilitarian thinking, you know, they've been doing a lot of cutbacks and they've essentially given up on PC VR. They don't care about it, but this is something that is for the broader XR industry. And, um, Matthew says that a developer who is using anything that is claiming to be like OpenXR middleware expects cross-platform and cross-vendor compatibility. Meta's OVR plugin prevents this from happening. Meta has no incentive to solve this problem since the content will continue to work on their platform. So anyway, certainly disappointing to see. I hope that Meta makes some sort of statement or maybe even the Kronos group comes out and makes even a stronger statement because, you know, what is happening with this middleware? If you're creating plugins that aren't actually implementing the OpenXR conformance, then maybe there needs to be new lists of plugins that are conformant with OpenXR conformance. Maybe there needs to be new levels of conformance. There's the normative best practices that are being violated here, and Kronos Group doesn't seem to be willing to have any way to enforce it. And it's a consortium of lots of different companies, and so there's a bit of bureaucratic inefficiencies to try to handle from people who are not following the best practices or rules. So anyway, hopefully they'll make either some statement, at least at the minimum, or they'll make an acknowledgement and go back and revert and actually properly implement the OpenXR standard. I think that would be ideal. Guy was saying that that may require them to do additional testing or whatnot on their end. And I don't know what the additional load is, but they should be able to at least take out some of the specific checks that they have, all these things that are detailed in Matthew's technical specification. Yeah. So anyway, it's very sad to see. It's sad. And I don't know what else to say. Hopefully they'll say something about it. So that's all I have for today. And I just wanted to thank you for listening to the Voices of VR podcast. And if you enjoy this type of coverage, then please do consider becoming a member of the Patreon at patreon.com slash Voices of VR. Thanks for listening.
