Steam VR had a notable update on June 14th. Not so much in what was introduced in the patch notes itself. But in the backend: we got a ton of new systems/strings related to Valve Deckard. The next HMD from the company who runs Steam.
Join me as I walk through the most notable things that me and my fellow dataminers have found.
New System Menu
The most notable thing that was found in the strings (and later activated via some tweaks to the code) was a set of new menus that are clearly meant for a product that does not exist. First let’s talk about how Steam VR has a System menu. If you have ever used a Steam Deck, you might recognize that the UI for this page is very similar. The ability to update a device, see status of an update, and even choose an OS Update Channel are all copied over from the Steam Deck. Valve’s Portable Handheld PC.
The OS Update Channel would show you a variety of different builds you can access. Such as a Beta OS build that will let you test features ahead of time. And a stable public build. Possibly more. These update systems do not work. The code references json files needed to be able to request what builds are available from the central server (/linux_update/get_channels.json). But since we don’t have that JSON file, there is no webserver routing, as of yet, to receive updates from. You may also notice a major difference to this menu from the Steam Deck UI is the fact you need to indicate where a PC has a Steam VR install. You cannot change anything within this prompt as of yet. But as I will explain soon in the Valve Deckard Recap Page – The base Deckard is likely to use an ARM chip to become a “smart PC VR HMD.” And will still require routing to a PC. Whether that is strapped directly onto a headstrap mounted compute unit. Or wirelessly connected. System Update will not change Steam VR itself. But likely the firmware on the Deckard
XRService Cal
On the System menu, there is also our very first reference to an XRService Cal. This is the first time we have heard of such a system within Steam VR. But it is definitely an important layer that Deckard needs to operate with. Our current speculation is that it is part of Valve’s new camera-based tracking system. From my research, Valve has a lot of interest into applying some Mixed Reality cameras to their headset as well to do Video Passthrough AR. This interest comes from patents, lots of driver updates related to cameras on lighthouse HMDs, comments from Gabe Newell, and confirmed partnership work with a computer vision company known as Arcturus Industries. If you watch their public demoes, they show off a lot of systems related to using cameras to do SLAM and virtual reconstruction of areas.
This XRService Cal string in the menu will seemingly just show the date and time of the last time you did the calibration. This might be useful for developers only. And a good way to hint to people like me: “hey we are actually doing this.”
It is important to note that we have speculated for a long period of time that Valve would allow the ability to track without lighthouse base stations. Sources from Ars Technica confirmed our suspicions as well. But Valve is not giving up fully on the lighthouse tracking system that many PC VR enthusiasts like myself use for things such as Full Body Tracking.
Deckard Devtools and Lighthouse Pairing
Lighthouse has been an incredibly useful tracking system for VR HMDs and more importantly: accessories. Applications like VRChat thrive because they adopted the ability to use things such as Vive Trackers to allow Full Body Tracking for avatar expression. The main issue people have had with Lighthouse comes primarily from the difficulty in adoption. Especially for people who cannot drill holes in walls. Or just live in small rooms in flats.
Valve is seemingly wanting to change this by incorporating both Camera based tracking AND the option to still use Lighthouse base stations/peripherals with Deckard. In the picture posted above, we have the very first reference to something called “Deckard Devtools.” Dev obviously stands for developer. And there seems to be a subset of systems that would allow developers to tweak games/overlays/services to work in parity with the Deckard. We do not have the full list of systems that these Deckard Devtools include. Except one: a fully fleshed out menu system that allows users to pair lighthouses and lighthouse dongles to Deckard itself.
We are not sure how fully the functionality goes for Deckard itself. But we did figure out how to access the new menu within VR. It’s something that people in the Steam VR community has wanted anyway, without a new HMD. And it actually functions the way we would like it to.
New Internet Menu
One of the main benefits of incorporating an SoC into Valve Deckard would be the addition to include accessible wireless technology. The Quest 2 makes up nearly 50% of all headsets connected to Steam VR and it’s not hard to see why. It is sold at a loss, but also: It has applications like Virtual Desktop and Air Link that makes wireless PC VR easy and accessible.
Another new menu added (and activated with tweaks to the code) is the “Internet” settings menu. It’s honestly pretty self explanatory. Steam VR is adding systems that will allow a PC to set up a “Wi-Fi Hotspot” for Wi-Fi enabled HMDs like Deckard to easily connect to. Currently it’s notable that the code mostly is bound to Linux endpoints.
Strangely enough – the menu and code suggests the ability to list multiple HMDs connected. I don’t know if this would be meant for Location Based experiences that would likely enable easy multi-communication between headsets? But the functionality is somewhat there.
The last final note to this section is related to strings. These Access Point features are littered with references to a new set of drivers that don’t exist on the Public version of Steam VR. The set of drivers it is looking for is called “cv_hmd.” I am not going to speculate myself on what CV stands for. There are a couple obvious ideas you can lead yourself to. One thing is for sure though: one day, we will probably get a new folder in SteamsteamappscommonSteamVRdrivers that will enable this functionality and possibly give us a heart attack.
Foxnet Returns
On October 1st, 2021: I did a live stream where I plainly set out all my predictions on what the Valve Deckard would be. And I have to note: most of the things I said in that stream, still stay true for my predictions today (except for Varifocal Optics).
The one final piece that allowed me to string together a picture of the Valve Deckard came from a leaked Steam Deck Firmware backup accidentally published by a Valve Developer. Within this firmware, there was only a couple files within Steam OS 3 that mentioned Deckard. And they all were in a folder named “foxnetstats”. In this folder was a set of Python files that were named: coremodules.py , steamvr.py , and finally deckard.py. Within the Deckard named file, Valve accidentally shown us what type of SoC was inside a version of Valve’s upcoming HMD.
The picture listed above shows all the cores that Valve was interested in recording thermal temps for. To the untrained eye, this might not tell you a lot about the SoC being logged. But for people who follow this industry in ridiculous amounts: One thing is certain. It shows proprietary cores that Qualcomm includes in all of their SoCs. Including ones like the XR1 and XR2. So we gathered that Valve was interested in one of these chips this for their own Headsets. (We just couldn’t tell if it was the Same XR2 in Quest 2)
But wait, Valve has repeatedly said that an x86 AMD APU like the one in the Steam Deck would help them run standalone VR? Well again: they do have plans for that. But I think as an upgrade path. I expect Valve will focus on modularity and their enthusiast PC VR community first.
To get back on track, we heard nothing of FoxNet since that leak. The Steam Deck came out and had no references anywhere within the code. I want to reiterate how lucky we were that the Valve employee seemingly backed up his own firmware rather than using a blank slate. Deckard would be way more mysterious without that mistake.
As of Steam VR 1.23.2, the backend code finally has references to this Foxnet service. And we find out that it is based on an application called “WireGuard.” WireGuard is a secure VPN tunnel. The reason for a VPN tunnel is something I will leave to your imagination.
New Theater Mode
I have reported a lot in relation to a new Theater mode being worked on for Steam VR. For those who do not know, Steam VR has used the same method to allow players to play flat screen games in VR since the HTC Vive released in 2016. It ran on Unity. Was slow and ugly. No one wanted to use it. Six years later, they finally decided a new system needs to be introduced.
Instead of requiring a brand new application to open alongside the non-VR game itself – Valve is using the backend of their Steam VR desktop/overlay system to build it. This is not only way more performant, but also leads some really neat possibilities related to Mixed Reality. One of the most common mentioned use cases for AR is the idea that it can replace a large size TV that can be moved anywhere at any time. The problem with this idea up until now has been the fact no one has wanted to watch/play non-VR content on bulky/large + low resolution HMDs. However if you followed my channel enough: you might be noticing that both of those things are changing in the next generation of XR hardware. Headsets are getting lighter, thinner, and much higher resolution. And with the XRCalibration that alludes to being able to map out a Real World environment for continuous placement: I think Valve is setting up the systems for this.
Currently what’s built into Steam VR in regards to the theater mode IS activatable via string tweaks. However the experience is not polished whatsoever. I want to mention that my dream for a system like this would be to allow integration of Steam Remote Play. And a virtual couch to invite friends together to play couch co-op in VR. No allusion to whether that’s happening. But it’s my dream.
SkyDome?
I haven’t talked much about this feature being added within the files. It’s just a set of new skybox-type images to Steam VR. And reflections they would give off as well. I thought it was a replacement for the standard skybox you would see while loading in between apps/games in Steam VR. But I am not so sure.
To top specifically doesn’t match up with the current way that skyboxes are rendered. So we might be seeing an entirely new feature or are awaiting a tweak to how skybox files are stretched. In SteamsteamappscommonSteamVRresourcesbackgrounds – Currently there is a SkyDome texture that is gradient black to gray, a SkyDome_Blue texture that is gradient blue, and a reflections texture that relate to the blue color more.
New Steam VR Room Setup
Now this is embarrassing. This is not a feature that was added in 1.23.2. It was added earlier, but we all missed it. That being said, it’s still a WIP and is totally a different way than how Room Setup currently works in Steam VR.
If you skip to 1:58 in this video I made, it will show you exactly how it works. The big benefit of this setup system (even though its unfinished) is that it allowed you to do it fully within VR. Unlike the current “official” Room Setup.
Standalone System Layer
This is the Valve Internal Menu. Just like the System and Internet menus: Its a hidden menu you can activate with some tweaks to the config files. This is where we enabled another menu that shown us the new WIP Room Setup. But it also allows you to enable different experimental systems such as Prism (doesn’t work) and the Standalone System Layer.
For a while, the Standalone System layer didn’t do anything except crash Steam VR. But now it actually does something… It disables the Steam VR Dashboard completely. As in, it doesn’t seem to run that entire layer within processes. Why would they do that?
Well to me: I speculate that Valve’s next HMD will have it’s own UI and “Dashboard” built into it’s firmware and SoC. But Deckard still relies on communication with Steam VR on PC to access the feature sets and more.
Patent and Wrap Up
This pretty much ends my overview and explanation of all the backend systems we found within Steam VR 1.23.2 Beta. Again, it’s a ridiculous amount of stuff this time. And the stuff they purposefully let out to us feels eerily similar to when Valve let out the info that let xPaw figure out that they were making a handheld gaming PC known as SteamPal (later Steam Deck).
Valve also had a utility patent application published showing off continued work on this concept of communication between the “front display housing” and the rear housing on the strap. I still stand by my predictions on how Deckard will one day become a full Standalone PC VR HMD. Even if it possibly doesn’t release with an x86 APU at launch.
Articles like this will continue to be published. I rather people use this as a resource for regurgitation/video scripts than my twitter. And I thank Valve for giving me and my other XR enthusiasts something fun to do once in a while. Much Love from all of us.
Bradley Lynch is the creator of the SadlyItsBradley YouTube channel. He and others on his Discord frequently analyze code in updates to SteamVR. His recent post analyzing a June 14th update is reprinted here with permission.
