Ok. Bad news: there is no easy fix possible. Good news: there is a workaround.
Unfortunately, SetControlRotation is very crappy function. It is used by many ‘clients’: mouse, keyboard, HMD, user. It is impossible to distinguish the user-called SetControlRotation from other, internal calls.
Thus, the initial set of the control rotation is just ignored by HMD and HMD overrides it.
The only solution I see is to separate internal calls to SetControlRotation from the user-level calls. But it will involve serious re-design of UE core and it is not gonna happen now.
However, there is a workaround. You may use Oculus Function Library, method SetBaseRotationAndBaseOffset (InMeters or not - doesn’t matter, we use only rotation part of it).
So, instead (or in addition to) of setting SetControlRotation set the base rotation of HMD. Note, the rotator from GetControlRotation should be inverted.
One more note: if you need to make it work at startup (like on the screenshot), you’ll need to modify OculusFunctionLibrary.cpp, methods SetBaseRotationAndPositionOffset / SetBaseRotationAndPositionOffsetInMeters: you should remove the “GEngine->HMDDevice->IsHeadTrackingAllowed()” condition from the “if”-statement there (this fix will be in 4.11, hopefully).
I suppose, we need to discuss this issue with Epic guys and decide what to do in long term, since this solution will work only for Oculus (Rift / GearVR). And another suggestion: in 4.11, the Camera Component will have a property ‘Lock to HMD’, meaning it will follow HMD orientation/position and this should be the main way how you work with VR in UE. The PlayerController-“automatic VR” is just for drop-any-project-in-and-run-in-VR-effortlessly kind of things, it is not good once you need to do something fancier than just look around in HMD.