Skip to main content
Elecman
Up and Coming
July 26, 2014

Getting rid of health and safety warning

What is the proper way to get rid of the health and safety warning in Unity?
In OVRDevice.cs, I tired commenting out this:

if (HMD != null && Input.anyKeyDown && HMD.GetHSWDisplayState().Displayed)
	HMD.DismissHSWDisplay();

and adding this to the end of Awake():

HMD.DismissHSWDisplay();


But that only works in the Editor but in the standalone version the head tracking stops working and the warning is not removed.

    261 replies

    Show previous replies
    guygodin
    Up and Coming
    July 27, 2014
    "PathogenDavid" wrote:
    Have you tried just leaving it out? You shouldn't even have issues with jumps in frame timing since ovrHmd_BeginFrame/EndFrame uses ovrHmd_BeginFrameTiming/EndFrameTiming internally.

    I think I tried in 0.3.x but it didn't work, I'll give it a another try with the latest SDK, thanks for pointing that out!
    Virtual Desktop Developer
    ElecmanAuthor
    Up and Coming
    July 27, 2014
    By the way, what is wrong with displaying the warning on the box or a piece of paper?

    Last time I checked, my washing machine didn't come with a projected in-my-face warning. So is that really necessary?
    ElectricMucus
    Up and Coming
    July 28, 2014
    "Elecman" wrote:
    By the way, what is wrong with displaying the warning on the box or a piece of paper?

    Last time I checked, my washing machine didn't come with a projected in-my-face warning. So is that really necessary?

    So true,

    The thing is the cooperate drone they hired as a lawyer couldn't sanctify the outrageous paycheck he got if they did.
    ElecmanAuthor
    Up and Coming
    July 28, 2014
    "ElectricMucus" wrote:
    the cooperate drone they hired as a lawyer couldn't sanctify the outrageous paycheck he got if they did.

    LOL :mrgreen:
    whitehexagon
    Up and Coming
    July 28, 2014
    Still waiting for DK2, but is it true there is a placeholder on that notice for facebook ads ;)

    But this does sound very clumsy. Imagine a TV doing that every time you turn it on. What's wrong with putting it on the packaging before you unwrap the device?

    Seems to me like this 'custom driver' is a step backwards from 'just another monitor' approach and opens the door for more unwanted spyware or content being forced upon developers and the device. What's next, a warning every 1hr of use?
    DK2, MBP (mid 2010) OSX 10.10.3. Win7 - i5 4670K - GTX770. Java LWJGL 3 OpenGL Experiments: https://github.com/WhiteHexagon
    PathogenDavid
    Participant
    July 28, 2014
    "whitehexagon" wrote:
    What's wrong with putting it on the packaging before you unwrap the device?


    Yeah, this has been mentioned in this thread. I hope we get an answer from Oculus on why or why not. My main guess is that only the primary owner of the Rift would have seen it, but you don't know if the current viewer has.

    "whitehexagon" wrote:
    Seems to me like this 'custom driver' is a step backwards from 'just another monitor' approach


    To clarify, this new warning is part of the SDK, which has always been around and required. It isn't part of the display driver, that's a different issue entirely. While the driver is problematic right now, I agree with Oculus that it will make the product more professional and user-friendly. I'd be surprised if most consumers even know what "extended mode" is for monitors in the first place...

    Although, there are probably better solutions in the short term. IMO, this is the best long-term solution if Oculus can make it work.

    "whitehexagon" wrote:
    and opens the door for more unwanted spyware or content being forced upon developers and the device. What's next, a warning every 1hr of use?


    Holy FUT! :roll:
    ElectricMucus
    Up and Coming
    July 28, 2014
    "PathogenDavid" wrote:
    [o clarify, this new warning is part of the SDK, which has always been around and required. It isn't part of the display driver, that's a different issue entirely. While the driver is problematic right now, I agree with Oculus that it will make the product more professional and user-friendly. I'd be surprised if most consumers even know what "extended mode" is for monitors in the first place...


    That is just a severe departure of the "open source" approach the SDK used to. Right now the driver is just a binary blob which can do who knows what. That it isn't straight forward to disable the warning leads to the assumption that the warning is at least partially inside that binary blob.
    That's my attitude toward it right now, that will change when the full source code for the runtime is provided.

    Besides AFIK in windows, a "driver" can consist of nothing but a simple .inf file.

    Next it's really problematic for other platforms, on Mac and Linux there are other problems and other methods which perhaps work even worse.

    My point is: It's premature, they should have released the runtime driver functionality later on and first got the SDK mature enough so that everything works, on all platforms.
    PathogenDavid
    Participant
    July 28, 2014
    "ElectricMucus" wrote:
    That is just a severe departure of the "open source" approach the SDK used to. Right now the driver is just a binary blob which can do who knows what. That it isn't straight forward to disable the warning leads to the assumption that the warning is at least partially inside that binary blob.


    This is an unrelated issue, but I do agree. If you look in the Mac/Linux nagging thread (I know you are watching it too), I am in support for seeing those bits open sourced as we've come to expect.

    What I am trying to say, is that 0% of the health and safety warning is part of the new binary blob parts. It is all in the open source portions of the SDK, and can even be disabled without modifying the SDK if you are willing to use an undocumented, experimental function.

    "ElectricMucus" wrote:
    Besides AFIK in windows, a "driver" can consist of nothing but a simple .inf file.


    And inf file is more of the configuration information that defines how Windows is allowed to load the driver binary, some simpler devices can just re-use existing drivers and only use an inf file to tell Windows that it is OK to use a specific driver for the device.

    Also, the direct HMD mode and service stuff is not really relevant to this thread, so let's keep that discussion in the relevant threads.
    ElectricMucus
    Up and Coming
    July 28, 2014
    "PathogenDavid" wrote:
    What I am trying to say, is that 0% of the health and safety warning is part of the new binary blob parts. It is all in the open source portions of the SDK, and can even be disabled without modifying the SDK if you are willing to use an undocumented, experimental function.

    Alright, can you please tell us? Because how it looks now disabling that will probably the first thing I'll do once I get my DK2, NFW I will look at the thing every compile/test cycle.
    PathogenDavid
    Participant
    July 28, 2014
    I've mentioned a few things in this thread, but if you're using the SDK directly: You should be able to disable it by just calling ovrhmd_EnableHSWDisplaySDKRender(hmd, false) (No modification to the SDK necessary, you will need to include CAPI_HSWDisplay.h though.)

    If you're using Unity or Unreal Engine, you'll have to do something else. I don't have any experience with LibOVR on either so I couldn't tell you what you need to do.
    Show more replies
    Terms & ConditionsAccessibility statement