Request to disable burn-in protection — medical use case (PTSD eye therapy)

Homepage Forums Technical Support Request to disable burn-in protection — medical use case (PTSD eye therapy)

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #222920
    Maximus0079
    Participant

    Hi Ralph,

    I’m using vorpX with a Bigscreen Beyond while lying down and staying perfectly still. This is part of a medical protocol — I’m treating post-traumatic stress from a polytraumatized eye and maintaining bifocal fusion through VR. The immersive environment allows me to enter self-hypnosis, which is essential for my therapy.

    The burn-in protection kicks in after a few seconds of immobility and stops frame submission, which breaks the immersion and makes the therapeutic process impossible. I cannot move my head — that defeats the entire purpose.

    Could you please provide a way to disable the burn-in protection? A config toggle, a hidden setting, a command-line flag — anything would work.

    I want to be transparent: I’ve spent considerable time trying to work around this on my end, without success. Here’s what I’ve tried through a proxy DLL replacing vpenvr_api.dll:

    Hooked IVRSystem::GetTrackedDeviceActivityLevel (vtable slot 15), force-returning UserInteraction
    → 0 calls observed across entire sessions, despite correct hook installation with readback verification

    Injected pose jitter via IVRCompositor::WaitGetPoses and IVRInput::GetPoseRelativeToNow/GetPoseForNextFrame (up to ±50mm / ±5°)
    → no effect

    Async thread writing Block B of vpx_vorpxinterprocess shared memory at 70Hz during Submit gaps
    → no effect

    Hooked LoadLibraryA/W/ExA/ExW to intercept any separate loading of openvr_api.dll
    → 0 redirections, not used
    Binary analysis: no “idle”/”burn-in” strings found, GetTrackedDeviceActivityLevel string absent from the injected DLL, vorpControl.exe contains zero OpenVR strings
    None of the OpenVR API channels are involved in the idle detection — I’ve eliminated every one systematically. The mechanism appears to be entirely internal to the injected DLL.

    I completely understand the rationale behind burn-in protection for OLED panels. But in my case, the content is never truly static (game scenes have ambient animation), and my medical need for complete immobility overrides the display concern.

    Would it be possible to add a toggle to disable this feature, or could you point me in the right direction?

    Thank you for your time and for an otherwise excellent piece of software.

    Best regards

Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.

Spread the word. Share this post!