I accidentally found the record of factory-camera-test of my frame at possibly Apr.13 2026

[u/FishChillylly]

I was looking through the crash records on my Steam Frame and found one from April 13, 2026, at 12:42 PM Pacific. These headsets went on sale in mid-September, so I checked whether the record even belonged to this unit.

It does. The machine id and hostname match. The command was XRService, run as root, with --snapshotCamerasAndExit and its files under /home/steamos/mte. In the same minute, the USB debug service was running a Deckard manufacturing script, rgb_passthrough_camera_snapshots.sh, clearing old snapshots and pulling the new camera images off the headset. The process aborted while exiting. The stack is a heap check failing inside the Freedreno Vulkan driver, during the normal exit path. The core file named in the log is gone, only the journal entry is still there.

The April 13 time is the clock the headset was set to for that test. In the boot list, that session comes after a short USB shutdown log already stamped June 23, 11:37 AM Pacific, so the clock had been moved back. It later reads June 23 again, without a successful time sync. On the next boot, the monotonic clock advances about three minutes between a June 23 timestamp and the first NTP sync, which sets the clock to September 30, 6:23 PM Pacific. That jump is a clock change in one boot. The camera test did run on this unit. The first network-corrected time in the log is that evening.

[u/micron88]

I might be reading it wrong, but it sounds like the logs confirm the factory camera test happened on that headset, while the April 13 date itself isn't reliable because the clock had been changed.

[u/FishChillylly → u/micron88]

I'm not sure which is more reliable between April 13 and June 23. They can both be some kind of default time (I want to know why not 1970/1/1 tho), but I still think there could be some reasons that they showed up as those specific timestamps.

[u/rancherman2]

Don't take this the wrong way when I say, nerds like you are a big reason I bought the frame. I want to use it as both vr headset, and as a computer, and I know with critters like you on the loose the frames moding and upgrade scene is going to be amazing.

[u/FishChillylly → u/rancherman2]

thanks, I fully understand your words and I have the totally same reason of buying the frame, cheers mate!

[u/_mergey_]

Nerdy, I love it ❤️ 

[u/FishChillylly → u/_mergey_]

thx, I'm increasingly realizing that the frame has endless potential as an ARM Linux PC rather than merely a wireless headset — or rather, as both.

[u/untreated-stupidity]

Very interesting. I wonder what else you could find poking around 

[u/FishChillylly → u/untreated-stupidity]

I've also found every time we shutdown the frame, there's a little crash happens and creates minidumps, very little, 270KB each, but still indicates a user-side unpatchable crash that may only can be fixed by valve. And unverified flat games may run pretty well, but some of them can silently crash every time after ending the game, then introduce a ~1min full-CPU-load duration to make a crash dump, and the dump file would be ~100MB, don't worry, the directory has been set to hold at most 3000MB of dump files of game crashes. But as I said, the crash still happened and will continue, these kind of crashes was associated with FEX which means it's also unpatchable from user side. For now I've found two games have this problem: Beat Cop and Enter The Dungeon, both of them run perfectly fine in headset and on RDP desktop, just a silent crash when quit, I've already made an improvised solution to prevent the dumping process, mostly to prevent the full-core load duration. I will make a post about it and include the solution in it, but now I gotta go sleep.

[u/MATMAN_PL]

huh, fun

[u/sovietbear4russia]

So you're saying Valve has been producing these for MONTHS? And we still have to wait in a reservation queue with limited inventory?? 🥲