Oculus Input Emulator for Selfmade Rifts?

There are lots of projects on the web for using an embedded processor as a HID keyboard emulator. One of those could be modified to emit HID packets as required by the OculusVR SDK.

There are also posts at MTBS3D about writing Rift DK EDID data to a I2C serial EEPROM memory device and it was correctly identified as a Rift DK video monitor. But many microprocessors also have I2C and could possibly provide both HID and EDID data, if required.

Although possible to make a software-only HID emulator, it would probably need a digital signature, and even if not, it would be a complex and tedious task, which may be of limited use.

It may be simpler to make your DIY Rift act like an Oculus Tracker DK device. You could patch and recompile the SDK if needed, and you could even add support for other devices. The newer Apache license may allow that, but for personal use (that you do not distribute), licenses and Terms of Service are less of an issue.

None of these options are as simple as tracking down a software package and installing it. Sorry about that, but Real Life is not always easy.

Could you point me to the threads on mtbs3d with the discussions about the I2C?

I happen to have a selfmade EDID spoofer and could give it a shot. But I always thought the rift-features are enabled by the tracker and not the display. Am I missing something here?

Is there any documentation on how the HID packets are structured for the rift?

"skyworxx" wrote:
Could you point me to the threads on mtbs3d with the discussions about the I2C?

I happen to have a selfmade EDID spoofer and could give it a shot. But I always thought the rift-features are enabled by the tracker and not the display. Am I missing something here?

Is there any documentation on how the HID packets are structured for the rift?

Here is the I2C EDID spoofing information you requested:
http://www.mtbs3d.com/phpBB/viewtopic.php?f=140&t=17054&p=120434#p120434

The OculusVR Tracker DK HID packet structure is defined in the OVR_SensorImpl.cpp module in the SDK. Just examine the UnpackSensor() and Decode() functions.

While examining the bit masking and shifting in those functions, notice that there is really no need to mask off shifted-in zero bits, or to mask off LSB "noise bits" when those noise bits are actually more accurate than masking negative numbers to zero when they should be extended with a sign bit (which would be automatic anyway if intrinsic arithmetic shifts were to replace those logical shifts of signed numbers).

Anyway, that code could be simplified a bit. The sign extension bit-hack it uses is part of a much larger collection I have used for many years. You should follow the URL posted in the code and check it out.

*** IMHO, others need to improve their Google-Fu (and for their HDD use "Search Everything" from voidtools to find files, and Agent Ransack to find stuff inside files). I spend too much time looking stuff up for people. I mean, how hard is it to search MTBS3D for "I2C EDID" anyway? And searching the SDK to see exactly how *IT* extracts data from HID packets isn't all that difficult to figure out either, for that matter. Just do it... practice makes perfect, and good "Google-Fu" is a valuable asset, so learn to use it...
:?