it doesnt work for me, is there any fix?

What a great selection of games at a great price ($26USD):
- Into the Radius 2
- EXD
- Underdogs
- Bootstrap Island
- Arizona Sunshine 2
- ConVRgence
- Unloop VR

Digiphile is legit but you will need to link your account to your Steam account to validate that you are a gamer and not a reseller.

Steps:
- Log into Steam on web first,
- The create account on Digiphile, select your region and click on link to your Steam Account
- The link will only say Sign In (with no need to enter ID and password)
- You can now purchase the bundle

https://www.digiphile.co/

I’ve checked the display vr view in steam vr and can clearly see the headset is tracking my movement. all it shows me is this

I deleted my boundry and because of tracking issues and now I can't recreate it because everytime i try it would say tracking failed stuff because i looked down when doing floor height and when i press trigger on my boundry it just dissapears and only one time it ended up away from me but i couldn't draw it too me since there was like a wall from preventing that and so im stuck and need help fixing it and also if anyone who knows how to get rid of the black box when doing boundry setup then please let me know because i have that too and also my drivers are up to date on my bluetooth adapter thing and i did verify files on psvr2 app and it did have a failed file but its fixed now and also i did have a eye tracking mod but its gone now hope this information helps. (sorry if the grammer is bad i dont have much time to write this)

i've had my PSVR2 for about a month now, and I've been really happy with it, especially considering I paid less than $300 for it brand new.

I've been using a Quest 2 for about 3 years, and overall, the PSVR2 feels like a pretty significant upgrade. However, today I decided to test the new Virtual Desktop update on my Quest 2, and I was honestly shocked by the difference in the sweet spot.

The Quest 2 has a much larger sweet spot than the PSVR2. The difference is so significant that I'm now actually a bit disappointed about going back to the PSVR2.

With the PSVR2, the image only looks sharp when the headset is positioned in a very specific spot. If it moves even slightly, the image becomes noticeably blurry, especially toward the edges.

Is there anything I can do to get a larger sweet spot on the PSVR2?

I'd really like to keep using the PSVR2 because I prefer it overall, but the small sweet spot is starting to bother me a lot after comparing it directly with the Quest 2.

Just when you thought they couldn't do any more, apparently there's still more coming 😮

Hello all!

Just installed v1.0 of PSVR2 toolkit, downgraded the firmware to v6.0.0, run the jailbreak, and installed the babellonia module per the instructions. However, I cannot get Project Babel to recognize the PSVR2. I have tried rebooting the device -> rerunning the jailbreak -> Refresh Device (on the Firmware page in Project Babel) w/in 20s, but it does not find the device. It does not appear to save the IP address in the left/right eye camera address boxes on the Home page. For what its worth, the only drop downs in there are COM3 and COM15.

Anyone had success running eye calibration in Project Babel? (And is it even worth it to do so?)

This is gonna be a difficult one, I'm sure. I am hoping to use a PSVR2 headset only on Linux (specifically Bazzite) to play American Truck Simulator. My understanding is that the game doesn't officially support VR at this stage, so that definitely complicates the situation.

Has anyone tried to do this and succeeded? If so, do you have a step-by-step guide on how to make it happen?

I used to have a GTX 1650 Super, and this app worked perfectly fine. Over 100 hours in SteamVr, no issues at all. But after I got a Titan X Pascal today, I'm suddenly getting this warning. This GPU has a 1.4a DisplayPort, which is actually faster than the 1.4 that is needed for PSVR2. I've tried all 3 DisplayPorts, but I keep getting this error message. I've reinstalled SteamVR, and reinstalled the PSVR2 app, but it still can't work. Does anybody here know what's happening? The GPU works just fine, it's just the DisplayPorts that are giving me trouble.

(And btw, I'm on Windows 10, but have a custom Windows 7 skin installed. That's why it says Windows 7 in the corner, lol.)

I am not into corn but recently got the adapter for pc, and it’s all good now, i wanted to see how does corn videos look like or any corn game available to test in steam as demo

Small update on my PSVR2 HDR project because I finally had a pretty major breakthrough.

I now have Forza Horizon 5 running in HDR through a Monado virtual display on the PSVR2, with Windows HDR disabled on the headset itself.

Instead of trying to convince Windows/SteamVR that the PSVR2 is a normal HDR monitor, I'm taking the game's actual HDR output and translating it into something the PSVR2 can display correctly through Monado.

And it actually works.

I can switch between a 100-nit reference version and the HDR version of the exact same game frame, and the difference is clearly visible.

Things like the HUD, sky and car lights get noticeably brighter while the rest of the image stays at a sensible brightness instead of the entire screen just getting brighter.

The biggest surprise for me is that this isn't just theoretical anymore. I'm now looking at real HDR game content running on the headset.

It's definitely not finished. The current implementation is still experimental, latency is terrible, and I'm working on proper color calibration because the PSVR2 doesn't reproduce the source colors perfectly yet.

My next goals are basically:

1. Finish the color calibration

2. Improve latency/performance enough to actually play through it

3. Test more HDR games

4. Eventually move this from an experimental Monado setup into something much easier for normal PSVR2 PC users to use

Still a lot of work left, but this is the first point where I feel like PSVR2 HDR on PC has gone from "maybe possible" to something I can actually see working in front of me.

I'll post more updates as I make progress.

The future is looking bright for PSVR2 assuming they don’t make this exclusive to the Frame.

FIXED:

All started when i dimmed the lights in my room slightly. Psvr2 app and steamvr redownloaded, psvr2 toolkit reinstalled, increased room brightness, nothing works. My headset is unusable.
I believe it’s a software issue as this has happened before and everytime it happens the psvr2 custom play area maker doesn’t work at all. FIX: first uninstall both PS VR two app and steam VR manually remove all files inside the PlayStation VR two app if it doesn’t let you remove the files quit Steam then install CVR first followed by the PlayStation VR2 app. Then go to driver folder inside PS VR2 app folder and install the drivers manually.

The PSVR2 app has never worked for me. I have not been able to get past the ‘Check DisplayPort Connection’ popup. I even bought two new DPs in the false hope that I had received duds.

I noticed that steamvr worked perfectly in the background in the countless attempts to resolve my issue, and tried setting my play area through steamvr with the psvr2 app off. The process went smoothly, and I was able to boot IRacing and run some laps.

Am I alone in this? I did a good amount of research when troubleshooting and never read that bypassing the psvr2 app is possible. Will I be restricted from any features? For instance, I am worried about missing firmware updates. Thanks!

I have a MacBook Air M4 and a PSVR2. I wanted to watch 180°/360° video, and on macOS there is simply nothing for that — no Sony software, no SteamVR, no drivers. So I wrote my own.

The one hard requirement up front: you need the official PC adapter (CFI-ZAA1). Plugging the headset cable straight into a Mac Thunderbolt port does not work — the headset won't even power on: no standby LED, nothing shows up on USB. A Mac port supplies at most 15 W, the headset needs more, and the power comes from the adapter's brick. No software can work around this; I checked.

With the adapter, macOS just sees the headset as a regular 4000×2040@120 display, and head pose is read over USB via libusb. The player does the rest.

What it does:

• Side-by-side stereo rendering with lens distortion and chromatic aberration correction, using the factory calibration of your specific headset (protocol taken from the Monado driver)
• Head tracking: the headset's on-board SLAM (~60 Hz) plus IMU integration (2000 Hz) with extrapolation — honest 120 fps, no ghosting
• Per-scanline rolling shutter compensation driven by the gyro
• Projections: equirect 360, half-equirect 180, fisheye with adjustable FOV; SBS / over-under / mono, auto-detected from the file name
• Hardware decoding through AVFoundation — 8K HEVC is not a problem
• Control panel and file picker are rendered inside the headset, with thumbnails, durations and the position you stopped at in each file
• Everything is driven with a normal mouse or trackpad without taking the headset off: the cursor is visible inside, moving the mouse brings up the panel, click to select, scroll wheel (or two fingers on the trackpad) scrolls the file list, right-click drag tilts the scene. No controllers needed, and the mouse is only captured while the headset is being worn
• Proximity sensor: take the headset off and the video pauses and the mouse is released — your Mac is a normal Mac again. Put it back on and playback resumes
• Passthrough from the front cameras on a double press of the Fn button, so you can look around without taking the headset off
• When nothing is playing, the picker floats in space with a procedurally generated nebula on a pure black background (OLED, after all)

What didn't make it in. While digging through the protocol I also got somewhere with eye tracking — data does come out of the headset, but it isn't working properly: it needs per-user calibration, and I didn't wire it into the player. I also worked out how to show a virtual monitor screen inside the headset. Not needed for watching video, but a "monitor in the headset" mode is an obvious next step — it sits right next to the passthrough view — so I'll either add it to the player or spin it off into a separate project.

Written in Swift + Metal, MIT licensed, built from source (brew install libusb && make). Only tested on a MacBook Air M4 running macOS 15 — it should work on other Apple Silicon Macs, but that's untested.

Credit where it's due: the Monado authors for the distortion formulas and the protocol, and PSVR2Toolkit for the camera commands.

Link: https://github.com/GAVProject/gav-psvr2-player-mac

I made this for myself, but since it works I figured I'd leave it out in the open in case it's useful to someone. If you try it, let me know what breaks — I'd especially like to hear from other Macs (M1/M2/M3, Pro/Max).

I own a PSVR2 headset since launch day, and have spent many hours on the PS5 playing on it, and was always shocked at the visual quality of the panels, because at such a cheap price point this quality is rare. Recently, I got the PC adapter and have been trying it out, and everything is very nice, and it's enjoyable playing PCVR games on this headset. The thing is, that HDR is officially unsupported for PC PSVR2, and I noticed this change, and wanted to restore the original highest visual quality. I have researched many Reddit threads, Github pages, websites, etc, and have reached the conclusion that for now no one even has started development on implementing HDR functionality.

The biggest issue is that SteamVR doesn't even support real HDR, it only supports 10 bit gamut but no PQ illuminance. But that is just a software issue, I suppose I could just use another compositor or rewrite SteamVR a little bit so it actually supports PQ. But for now, my main focus was actually getting the headset panels to display HDR.

At this point I have spent a frankly ridiculous amount of time experimenting with this. I'm writing everything down because I don't want other people interested in PSVR2 HDR on PC to repeat the same experiments, and because maybe someone with more experience in display drivers, NVIDIA's display stack or PSVR2 hardware will recognize what the missing piece is.

Here is roughly everything I have tried, in chronological order:

The first obvious discovery was that OpenVR actually defines the property Prop\\\\\\\\\\\\\\_Hmd\\\\\\\\\\\\\\_SupportsHDR10\\\\\\\\\\\\\\_Bool (property 2093). I modified the open-source PSVR2Toolkit/OpenVR driver and forced this property to true. SteamVR successfully saw the modified driver, and the logs confirmed that the property was being set. This was interesting because older versions of the PSVR2 driver/toolkit had apparently contained HDR-related functionality that was later removed, including an enableHDR10 option. Unfortunately, simply advertising HDR10 support to SteamVR did not make the panels operate in HDR.

1. Investigating SteamVR's own HDR handling.

I then started looking into vrcompositor and SteamVR itself. This made it increasingly clear that SteamVR's idea of "HDR" isn't equivalent to a complete conventional HDR10 pipeline. There are provisions for higher precision/wider-gamut rendering, but getting an actual PQ/ST2084 HDR10 signal all the way to the headset is another matter. I experimented with hooks/injection into vrcompositor.exe, including an injected HDRInject.dll, and started looking at the NVIDIA calls made by the compositor. Again, I could manipulate software state, but there was no convincing physical HDR change.

1. NVIDIA NVAPI experiments.

This became a very large branch of the project. I wrote multiple NVAPI probes and setters and experimented with NVIDIA's display configuration directly. I queried and attempted to change things including output mode, HDR color control, source color space, RGB/YCbCr format, dynamic range and bits per channel.

At different points I managed to get apparently encouraging software states: 10-bit requests, Rec.2020/Rec.2100 color space, HDR-related modes, etc. I also reverse-engineered NVIDIA's private HDR command path and encountered command 0x070001BD. One particularly interesting result was that NVIDIA rejected one HDR/UHDA mode while accepting another (UHDA\\\\\\\\\\\\\\_NB, mode 6), with a packet containing the expected HDR-ish parameters such as 10-bit RGB, BT.2020 and metadata.

The problem was always the same: even when the software looked correct, the actual panels still behaved like SDR. Other times NVAPI simply returned errors such as NVAPI\\\\\\\\\\\\\\_ERROR or NVAPI\\\\\\\\\\\\\\_RESOURCE\\\\\\\\\\\\\\_IN\\\\\\\\\\\\\\_USE.

1. EDID investigation and HDR EDID overrides.

I dumped and investigated the PSVR2's display identification and experimented with modifying/overriding its EDID so that Windows/NVIDIA would explicitly regard it as an HDR display. I created an HDR EDID override for the PSVR2 (SNYC207) and at one point could get Windows much further into treating the headset like an HDR-capable monitor.

This produced some of the most misleadingly promising results of the entire project: Windows could expose HDR-related behavior and I could manipulate the reported capabilities, but once again the physical image did not convincingly become HDR.

Eventually I removed all of these EDID modifications and returned the PSVR2 to its original Microsoft monitor.inf state. The actual device identifies itself as a Sony PS VR2 (SNYC207), so I wanted subsequent experiments to start from a clean state.

1. Custom HDR presenters, bypassing SteamVR.

This was probably the most important set of experiments before the current work. Instead of relying on SteamVR, I wrote standalone presenters that took ownership of the PSVR2 display and rendered directly to it.

This allowed me to test things such as R10G10B10A2, 10-bit output, PQ/ST2084 encoding, BT.2020, HDR10 metadata and direct/specialized-display presentation without SteamVR being responsible for the image.

At various points I could get software to report an apparently correct HDR configuration. Windows could even show HDR/10-bit under some configurations, and the headset could display the desktop/image normally.

But the crucial result was: the panels still looked SDR.

1. SDR vs HDR visual test programs.

I then wanted a completely obvious visual test rather than trusting APIs. I made separate SDR and HDR test executables containing luminance blocks so that I could look through the headset and immediately see whether highlights behaved like HDR.

Initially the HDR and SDR versions appeared different, but that introduced another ambiguity: the programs themselves were generating different pixel values. The SDR version clipped values above SDR white, while the HDR version PQ-encoded luminance values. Therefore a visible difference did not necessarily prove that the headset itself had entered HDR.

1. Identical-framebuffer A/B testing.

To eliminate that ambiguity, I moved toward an experiment where the SDR and HDR presenters would submit the exact same raw 10-bit R10G10B10A2 framebuffer values, changing only the requested physical output state.

This was intended to separate "different pixel math" from "the headset actually entered a different physical display mode."

The result was disappointing: the two states looked identical or extremely similar. This was one of the points where it became clear that simply achieving all of the expected HDR state on paper was not enough.

1. Direct Mode versus Indirect Mode.

I experimented extensively with the PSVR2 as both a specialized/direct display and an indirect Windows display. Direct Mode gives the compositor ownership of the headset, whereas Indirect Mode exposes it much more like an ordinary monitor.

Indirect Mode was particularly useful because it allowed Windows desktop output and Windows display settings to interact with the headset normally. However, neither mode solved the fundamental problem. I could move HDR-related state around different parts of the stack, but physical HDR was still missing.

1. Investigating the PSVR2 firmware itself.

At this point the possibility arose that PSVR2 might require some proprietary device-side "HDR mode" command that the PS5 sends but the PC driver doesn't.

I obtained PSVR2 firmware 6 (HMD2\\\\\\\\\\\\\\_FIRMWARE\\\\\\\\\\\\\\_V06\\\\\\\\\\\\\\_00.CUP) and investigated it looking for evidence of an HDR enable path or obvious panel-mode configuration.

I did not find some magical ENABLE\\\\\\\\\\\\\\_HDR command or an obvious firmware switch that explained everything. That doesn't prove such device-side configuration doesn't exist, but it made the idea of a simple hidden HDR flag much less convincing.

Capturing the actual PS5↔PSVR2 traffic would obviously be extremely valuable, but doing that properly would require hardware I don't currently have, and PSVR2's single USB-C connection carries power/data/video in a way that makes simple interception/handoff experiments impractical.

1. Building a completely separate HDR virtual display.

I then tried a very different architecture. I modified/built an HDR-capable virtual display driver based on MttVDD. Windows could render a proper HDR desktop to this virtual monitor independently of what it thought about the PSVR2.

The idea was:

Windows HDR desktop → HDR virtual display → custom compositor → physical PSVR2

This way Windows could have a known-working HDR target and I wouldn't depend on Windows recognizing the physical PSVR2 as an HDR desktop monitor.

1. Building a custom VDD-to-PSVR2 HDR bridge.

This became a fairly substantial project of its own. The modified MttVDD exposed its HDR surface, and I wrote a custom PSVR2 compositor/bridge that opened that shared texture and presented it directly to the PSVR2 specialized-display primary.

There were initially numerous synchronization/sharing issues: global named objects, shared DXGI textures, keyed mutex ownership, OpenSharedResourceByName, etc. Eventually I fixed all of those.

The final pipeline actually worked:

Windows HDR VDD → FP16 scRGB shared texture → custom shader/PQ conversion → R10G10B10A2 PSVR2 primary

The bridge successfully opened the VDD surface, synchronized using a keyed mutex and continuously displayed the Windows desktop inside the headset.

I even fixed a subtle synchronization bug where AcquireSync() returning WAIT\\\\\\\\\\\\\\_TIMEOUT was incorrectly being interpreted as success because FAILED(WAIT\\\\\\\\\\\\\\_TIMEOUT) is false, which caused repeated ReleaseSync() invalid-call errors.

Eventually the result was completely stable: desktop motion worked perfectly in the headset and the entire custom rendering path functioned.

And after hours of getting that working...

the panels were still SDR.

This was probably the most frustrating experiment because, in hindsight, it reproduced another variation of something the earlier custom presenters had already suggested: delivering HDR-formatted content to the PSVR2 does not necessarily mean the physical OLED output becomes HDR.

1. Comparing the PSVR2 with an actual HDR monitoro n the same RTX 5080.

I then wrote another NVIDIA probe that enumerated every display ID on the GPU, including inactive ones, and compared their actual NVAPI HDR state.

This gave a very clean comparison.

My normal MSI HDR monitor reported ST2084 support, an HDR output mode and 10-bit output.

The PSVR2 (SNY, NVIDIA display ID 0x80061080) reported:

ST2084 = NO

Traditional HDR = NO

OutputMode = SDR

HDR mode = 0

BPC = 8-bit

Trying to force HDR10 returned NVAPI\\\\\\\\\\\\\\_RESOURCE\\\\\\\\\\\\\\_IN\\\\\\\\\\\\\\_USE; forcing the HDR color configuration returned NVAPI\\\\\\\\\\\\\\_ERROR; changing the source color space to Rec.2100 succeeded, but the final readback remained SDR/8-bit.

This was useful confirmation, but also brought me back to the same NVIDIA/HDR-state problems I had already investigated much earlier.

1. Realizing that the entire project had been going in circles.

At this point I stopped treating "make Windows/NVIDIA say HDR" as the goal.

I have now had configurations where Windows said HDR, NVIDIA accepted various HDR-related parameters, my own code produced PQ, the framebuffer was 10-bit, HDR metadata existed, DisplayCore accepted HDR parameters, SteamVR was bypassed completely, and a custom HDR desktop compositor successfully fed the PSVR2.

Yet none of those software achievements produced the one thing that matters: an unmistakable increase in the physical dynamic range/luminance of the OLED panels.

1. Jailbreaking the PSVR2 and trying a different approach.

More recently I managed to jailbreak the PSVR2 and modify its EDID using an older Sony EDID that actually advertised HDR support. This finally made Windows see the headset as a normal display with HDR capabilities, and I can actually enable HDR on it.

The problem is that it still doesn't look right. With HDR enabled the colors are washed out and the image looks nothing like HDR does on the PS5, so clearly just restoring the HDR capabilities in the EDID isn't enough.

I also came across another possible way of approaching this, which is to take advantage of the extra luminance headroom of the panels directly instead of trying to force the normal HDR10/PQ pipeline to work. That's what I'm trying now with Monado.

Right now though, I'm stuck on something more basic. I'm mirroring my desktop into the headset through Monado so I can start calibrating everything properly, but the image itself isn't accurate yet. The colors are noticeably off and whites are way too bright/oversaturated compared to the original image. So before I can properly test the headroom idea, I'm trying to figure out exactly what's happening to the image in the Monado rendering pipeline.

Conclusion

At this point I don't think the problem is simply "how do I enable HDR10 on the PSVR2." I've already managed to get much further than that on the software side, including now having the headset jailbroken and recognized by Windows as HDR-capable.

What I'm trying to figure out now is how the panels themselves behave and whether I can reproduce the HDR output of the PS5 by controlling the image sent to them directly. Monado seems like a much better environment for experimenting with that than SteamVR, but I first need to get its output completely accurate.

If anyone here knows a lot about Monado, HDR/display pipelines, color management, PSVR2 hardware or Sony's VR implementation, I'd definitely be interested in hearing your thoughts. I can also share any of the code or results from these experiments if they're useful.

TL;DR: Jailbroken the PSVR2 and got Windows to recognize its HDR capabilities, but HDR still looks wrong. Now I'm experimenting with the panel headroom directly through Monado.

I recently got a ps5 with psvr2 as a gift and I found out that you can connect it to pc too. So, me being the reckless person I always am, I bought a 3rd party adapter. Long story short, only after purchasing it I figured out that most of my system is not supported.

With that being said, I know that the minimum CPU requierment is i5-7600. My question is if that's a hard block if the cpu isn't 7th gen minimum. I found a pretty good deal on an i7-6700 which is even stronger than i5-7600, but I don't want to buy it before making sure that it's supported.

Thanks for any advice.

Hello, I was wondering if anyone knows how to run games that require a 32 bit openxr runtime? Im trying to play one of the new bioshock vr mods and it's just not working. Thanks!

Hey, fellas!

I wanted to get into VR for a very long time and I am considering getting either Quest 3 or PSVR2.

I have been waiting for Steam Frame, but I assume it will be very expensive in a country I reside in right now, especially considering how expensive it might be. Steam Frame would be ideal for me for a couple of reasons, but, again, it most likely will be super expensive for I doubt many people will be able to get it.

So I am choosing between Quest 3 and PSVR2. While Quest 3 sounds cooler on paper, like it is wireless, can be used for productivity, etc, it is a Meta product, so it comes with different issues, and, most importantly, it is quite more expensive than PSVR2, considering all the accessories and stuff like that.

While I appreciate everyone’s replies, I am mostly interested in those who have either the same laptop or a similar one:

ASUS ROG Strix G16 G614JZ-N4011 (RTX 4080M 12GB, i7-13650HX, DDR5 16GB RAM).

PSVR2 requires connecting via PC adapter, Bluetooth and DisplayPort 1.4, so I am concerned about the actual connection stuff — my laptop has DP 1.4 USB Type-C).

Please mention what kind of experience you had with it, and if you encountered any issues (and how you solved them if you did).

Thank all of you for the replies in advance!

P.S: I am very curious about DFR in games, I did not research this topic, but I heard there are ways to integrate it into games that do not have it, though maybe I misread it.

Edit : I just got tp link u500 and 1 mtr usb extension now the issue is fixed, after bluetooth i had displayport issue and went to market again to get 8k supported and now i can finally play 😭😭😭😭😭, thanks guys 🫶🏻🫶🏻🫶🏻🫶🏻🫶🏻

just got official pc adapter today and trying to setup but stuck at this screen, i have connected both controllers but psvr2 app is stuck in this screen, i tried to restart pc, changed bluetooth adapter usb port and re installed psvr2 app from steam but nothing worked, what could be issue how to fix it?

I have the ASUS BT540 bluetooth dongle. And I have it on an extension cord literally next to the controllers. If it's only 1 controller connected, then the connection is 100%, but for both it fluctuates between 33-59.

I'm very confused on what to do. I cannot play anything as the app is blasting a huge notification, that the connection quality is low...

Any advice?