Basic Linux Rift library with OpenGL in C

user@lm32 /build/libnsb_ovr_0.0.2 $ ./consoletest
getSensorInfo: Invalid argument
Device Info:
	name:     Oculus VR, Inc. Tracker DK
	location: usb-0000:00:06.0-2/input0
	vendor:   0x2833
	product:  0x0001
CTRL-C to quit

sendSensorKeepAlive: Invalid argument
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
...
user@lm32 /build/libnsb_ovr_0.0.2 $ ./threadtest
getSensorInfo: Invalid argument
Device Info:
	name:     Oculus VR, Inc. Tracker DK
	location: usb-0000:00:06.0-2/input0
	vendor:   0x2833
	product:  0x0001
CTRL-C to quit

	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
	Q:+0         +0         +0         +1        
sendSensorKeepAlive: Invalid argument
	Q:+0         +0         +0         +1        
...

Still a problem, so like you said, probably Linux Mint 11, or VirtualBox. I will try a different distro later...

One question though: with my Rift unplugged (not selected in VirtualBox USB devices), I already have a HID device 0, so the Rift tracker becomes HID device 1. Do I need to change that in the code? It looks like your code scans for the device, and it prints the correct device ID information before trying to read tracker data.

EDIT: I did have to comment out that "update kernel headers" error in the header file again, like you suggested for the previous version. Installing Kali distro (the new BackTrack ) into a VM now...

It works great in a Kali Linux VM on VirtualBox. I just needed to install freeglut3-dev to build it. I did not try uncommenting that "update kernel headers" line, so I do not know if this distro needs that.

The next step is to test this on my Raspberry Pi. I hope it is relatively straightforward to get running in that environment...

Thanks! This is just what I needed. :D

EDIT: My RasPi is being a PITA (Pain In The Behind), so I did not test this yet. No matter what I do, I cannot get the wired network to work. The LEDs light up, but eth0 interface not working for me using the latest Raspbian linux distro. I find plenty for FUQs on this one (Frequenty Unanswered Questions) but none of the suggestions worked for me. I suppose I need to shuttle the SD card between it and my Win8 box, but then I cannot get Win8 to see the ext3 partition. I suppose I need to mount it in an XP VM so I can use EXT2IFS to read and write it. That too is a PITA.

I have my hopes up that this linux-compatible Rift head tracker library will work on my Raspberry Pi.

The good news is that this is working on my Raspberry Pi!

As I type this, my Rift DK is plugged into my RaspPi, and the tracker data being displayed responds to motions as expected, and is display changing tracker data on my Rift DK video display.

I had to comment out the GL stuff, because installing the missing stuff is not trivial with no functional networking on my RaspPi. For my app, I do not need it anyway because I plan to write directly to the framebuffer.

Now I need to get some head-tracked stereoscopic animation going on my RasPi, so this can be used by ordinary folks without needed to compile stuff...

EDIT: For anybody planning to build this from source code (including the OpenGL demo), you first need to install freeglut3-dev, which I have not done yet on my RasPi due to networking issues. I commented out OpenGL dependencies in the Makefile, so only the console apps are working for now. I plan to use the framebuffer first to display stereoscopic video on my RasPi. I can worry about GL ES 2.0 later...

Haha, I "quit graphics" when the only game in town became specialized and very restrictive hardware, so I have some sympathy. Now that these GPUs are basically like the specialized processors or DSPs I wanted in the first place, I'm okay with them!

I think the RasPi has SDL installed by default (I'm not certain because I would have downloaded it promptly if it isn't). You could use that instead of FreeGLUT as a system abstraction (open window, get input).

I'm working on a demo based on nsb's library here -- which should be GLES2/OpenGL4 compliant. Right now I only have some squares in a scene (wait... they are the scene), tracked by Rift. Adding the stereo options now. I'm using FreeGLUT because it's already a dependency, but it's really only used for opening a window and getting input -- easily changed to something like SDL. I'm not using any deprecated OpenGL functionality, so no glut primitives either. This also means the demo will be pretty bare-bones. No text or graphics primitives (err... ray-intersection primitives they should be called).

I haven't been using my RasPi lately, because my sister borrowed its monitor indefinitely... But using it as a network-accessed "Rift driver" would work nice. No multiple display headaches either. :)

"atavener" wrote:
... I haven't been using my RasPi lately, because my sister borrowed its monitor indefinitely... But using it as a network-accessed "Rift driver" would work nice. No multiple display headaches either. :)

The RasPi network interface uses an internal USB connection, so it only provides a 100Mbps LAN speed. It would be 4x faster to not use the onboard ethernet on the RasPi, but instead use 480Mbps USB Networking like we do on our eink Kindles:
http://wiki.mobileread.com/wiki/Kindle_Touch_Hacking#USB_Networking

The RasbPi ethernet speed is a lot slower than USB, and an optional Wi-Fi adapter on the RasPi would be even slower than that in many cases (although multi-channel 802.11N Wi-Fi might come closer to the raw USB speed if you really need wireless).

It is nice to see that there are other potential RasPi-Rifters here, so I do not have to feel so "all alone".

I am looking forward to your RasPi-friendly demo (and hopefully borrowing some source code from it). :P

"geekmaster" wrote:

It is nice to see that there are other potential RasPi-Rifters here, so I do not have to feel so "all alone".

I am looking forward to your RasPi-friendly demo (and hopefully borrowing some source code from it). :P

You are definetly not alone. I'd like to use the Rift with either and Android tablet and/or the Raspberry Pi, because those would be far more mobile solutions and would enable the Rift to be used as FPV goggles without bringing a laptop ;-)

"Sebbi" wrote:
You are definetly not alone. I'd like to use the Rift with either and Android tablet and/or the Raspberry Pi, because those would be far more mobile solutions and would enable the Rift to be used as FPV goggles without bringing a laptop ;-)

There will be those detractors who complain about all the things that the RasPi-Rift combo cannot do, but thankfully I am not one of those "glass half empty" pessimistic people. I am absolutely and eternally a "glass half full" optimist, looking to squeeze all the cool stuff out of limited hardware that I can.
http://en.wikipedia.org/wiki/Is_the_glass_half_empty_or_half_full%3F

Even WITH a limited framerate and/or reduced resolution, there will certainly be those who will choose to use the RasPi-Rift combo instead of a bulkier and heavier power-hungry device than can provide much more computing power than you need. And they will be very happy with it too.

It is all a matter of attitude and perception. Some people have it naturally, and some can learn it with exposure and experience, but some will never learn and will try to convince others to not even try...

For you and I and the rest of us who are in (or can choose to be in) the "glass half full" crowd, I look forward to sharing my Rift-Pi fun with you all...

Let the "glass half empty" souls stick to my "Rift-Pi" thread over at MTBS, and hopefully this forum can stay more on the upbeat side of things.

Here is a quick Raspberry Pi + Rift DK demo program that draws an animated wrap-around background and uses head tracking to let you look around, which you can download here:
http://www.mtbs3d.com/phpBB/download/file.php?id=2703

This uses ONLY the CPU, other than to push a framebuffer full of CPU-generated pixels to the display.

It is not finished. It cheats in a number of areas. It maps a couple of quaternion coordinates to yaw and pitch instead of converting to Euler angles. It relies on coincidental stereoscopic overlap of the animated pattern instead of drawing separate images for each eye. These cheats fail in minor ways occasionally (such as when you look left or right, which bends your motion upward, and when the color palette wraps around, which causes momentary wrong colors between the eyes). It needs a launcher script (included) to set the screen to 1280x800-32bpp. It draws on the desktop and does not clean up after itself (but the desktop is not useful yet with the Rift connected anyway, so I launch it from a root SSH shell). Be sure to make both files in the .zip file executable, and launch it with the pixelpi.sh script.

But as it, it demonstrates that we really CAN do interesting things on this hardware, and it will only get better with GPU support (which will have no problems with running a pre-warp shader).

Source code will be provided later after the dirty hacks are removed.

You can read some related comments about it here, if you want more (different) details:
http://www.mtbs3d.com/phpBB/viewtopic.php?f=140&t=17337&p=122747#p122747

"atavener" wrote:
Using libnsb_ovr_0.0.2, here is a demo I cooked up... using modern OpenGL and including distortion shaders.

Sweet, thanks for that. Be aware that there's an out of bounds error in the sendSensorScaleRange function within OVR_HID.c, for which I've attached a patch. Interested parties should inspect the patch, as I didn't perform a detailed analysis: merely eliminating the out of bounds assignment. I would have posted it sooner, but I've been busy playing with my Raspberry Pi.

It seems we aren't allowed to attach patches: "The extension patch is not allowed."

diff --git a/libovr_nsb/OVR_HID.c b/libovr_nsb/OVR_HID.c
index 5c4fa32..e776c0e 100644
--- a/libovr_nsb/OVR_HID.c
+++ b/libovr_nsb/OVR_HID.c
@@ -175,7 +175,6 @@ BOOLEAN sendSensorScaleRange( Device *dev, const struct SensorScaleRange *r)
     Buffer[4] = r->GyroScale & 0xFF;
     Buffer[5] = r->GyroScale >> 8;
     Buffer[6] = r->MagScale & 0xFF;
-    Buffer[7] = r->MagScale >> 8;
 
     res = ioctl(dev->fd, HIDIOCSFEATURE(7), Buffer);
     if (res < 0)

geekmaster: you are far from alone in your interest in tying the Rift together with the Pi. Raspberry Rift, anyone?

I've been learning about Aboriginal Linux (README), and preparing a target specifically for the Raspberry Pi. I've already set up a target for the arm6zk, but I haven't tried booting the Pi with it yet. Note: the pre-built armv6l Aboriginal binaries work with the Pi; I was able to boot the Pi using the official github kernel, and the aboriginal root-filesystem for armv6l (all on a 1G sd card).

Currently I'm reading about the Aboriginal miniconfig capabilities. I'm being lazy: the aboriginal build system automatically pulls in linux kernel 3.8, and the official linux for raspberry pi on github is 3.6.11. Instead of learning how to make the build system use a different version (which is quite simple, actually: just edit a file with a different name and SHA1), I thought it would be better to learn more of its capabilities: Q: What's a miniconfig?

What is Aboriginal Linux?

"RADME" wrote:
Aboriginal Linux provides virtual Linux images you can boot under QEMU,
within which you can compile and test any software you like.

The build scripts automatically create cross compilers and bootable system
images for various targets, such as arm, mips, powerpc, and x86....

The system images provide minimal native development environments which you
can boot under an emulator (or on real hardware if you have it) to compile
code natively. This includes a full native compiler (for both C and C++),
and the (optional) ability to run the cross compiler on the host (via distcc)
to speed up the build without reqiring the packages you're building to
know anything about cross compiling.