The first time that Valve added linuxARM64 binaries for SteamVR was all the way back in late 2019 after the Index launched
They would scrub these files from future releases after we released the first "Valve Deckard" video that me and my community members put together in 2021 🧵
Some of the most notable references to "Deckard" were found in the ARM Lighthouse binaries
The reference to deckard_appications.vrmanifest was, and still is, one of the most interesting
As far we know, this new type of vrmanifest file is still not being used by SteamVR
The first VRLink driver reference was also found back then. Only including a dll for a single Realtek Device
Was probably for a now-referenced "Steam VRLink Dongle" to make it easier to wirelessly connect Deckard to a PC
They repurposed and launched it on the Meta Quest store
Later in 2021, right before the Steam Deck launched:
We got access to a build of SteamOS 3.0 that had logging references to the Deckard hardware
Including "" which would list thermals of a Qualcomm XR2-like SoC deckard.py
Alongside that SteamOS "", there was also a "" file which logs different stats
We got another look at the Valve Deckard project using LinuxARM64 binaries in this file Deckard.py SteamVR.py
Around then, I started hearing whispers that Valve was funding the FEX project. Which is an x86(-64) to ARM emulator on Linux
And they were testing running SteamVR titles in early demoes of that work
I had trouble believing this. I often got false info from trolls back then
FEX is one of the important tools listed in the new ARM Proton leak from last Friday
If you have a good enough device, combining it with an ARM Build of Proton would allow x86(-64) Windows apps to run on LinuxARM64 systems
Speaking of the ProtonARM leaks: Many people are missing something important as they re-report the pure basics of what they found on @SteamDB
Earlier this year, we caught wind a new branch of Steam Apps that were tied to SteamVR
What is missed by the overall tech media: this "ValveTestApp" list of both regular and VR games being emulated to (linux)ARM64 is also a sub-App of the branch I just mentioned
And is listed alongside a few androidARM VR-only apps that stick out like a sore thumb
Valve is seemingly ensuring that developers who would want to easily port over titles from androidARM HMDs such as Meta Quest, ByteDance Pico, and... (well thats pretty much it) are able to do so
Valve recommends VR Apps to be built on OpenXR
WayDroid + OpenXR = Easier Porting
I should also note that any work being done here would also allow Valve to make/support other LinuxARM devices
I see a focus on pointing out the 2D titles as proof against any VR Headset
But signs point to Valve ensuring any AR/VR product they launch, supports ALL their library
One of the stats/logging modules in the earlier SteamOS Deckard leaks told us they plan to use their Gamescope compositor on Deckard
We have been following all the publicly available changes/commits to Gamescope due to this. Many of these changes are focused on VR Overlays
Similar to what Apple calls Spatial Computing, SteamVR on PC had a pretty great handle on this concept for a while
The idea of manipulating 2D/3D panels across your VR/AR space isn't novel
I believe Valve wants to implement these concepts for Gaming
Valve rebuilt their Theater Mode for VR to run as an overlay instead of an entirely different app
Something I find interesting: it has a recently added Stereo 3D function in the backend.. which is pointless for the majority of the Steam Library right now
I wanted to write this up because I missed an opportunity to predict the ARM leak in article-form months ago. And wanted to ensure that people see the leak in the same light as I do
I didn't publish it because I lacked the confidence to go through with it
Going back to my community's early datamines made me quite sad. Me and my friends spent many hours since 3 YEARS AGO trying to figure out the mysteries of Deckard
We were all fueled by the hopes/copes that it would come out sooner. But something like this takes a lot of (Valve) time, if it happens. Many of us have PTSD from misinterpreting previous datamines that would end up becoming Steam Deck, Deck OLED, and Steam Link for Meta Quest
Some of us have even stopped believing that Valve would release a VR headset at all. The latest leak from Friday gave me a boost of confidence. I still believe they will
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Still has finger tracking: "The disclosed linear hand strap adjuster does not change the user's grip on the handle, which helps to maintain a consistent finger placement on the handle, which, in turn, helps with the calibration of finger tracking sensors in the handle."
Valve has graced us with a new Steam VR Beta update. Showing a ton of software prepping for (assumedly) Deckard HMD
There is a new System UI that is akin to what was leaked before the Steam Deck was announced
Thread will continue with more leaks🧵
Within the settings menu: You will be able to pair controllers entirely in VR (without taking the HMD off)
Including resetting controller tracking data. Which hints to a new system for tracking controllers
They also added Internet Settings which is another feature you probably wouldn't need directly inside the Steam VR settings menu unless you were purposefully setting it up for a standalone/hybrid HMD
The source that confirmed to Ars Technica that I was on the right track regarding Deckard said Valve was looking to do Holographic Polarization-based Folded Optics
You can see why bright displays are so important. <10% efficiency at 10% duty cycle means 10K nits goes to 100…
LCDs can easily do this right now. Because they will push a MiniLED backlight to ridiculously high brightness levels. I read in a paper: they already target 10K nits
This is the main reason Meta is going with MiniLED for Cambria. I imagine they have a customized panel, as well
If Apple is going for similar optics, which undoubtedly: they will be…
Their OLED MICRODISPLAYS will have the be reaching these ridiculous levels too. Much more difficult in uOLED
It will be interesting to see how they manage it. Im guessing microLens arrays onto RGB subpixels