HID development pitfalls

"jherico" wrote:
I just discovered that the HID feature reports that should be read-only aren't. I accidentally trashed my Rift because the sample code for low level HID access on Linux (found here: http://lxr.free-electrons.com/source/samples/hidraw/hid-example.c ) writes to feature ID 9, which is what the Oculus uses for 'DisplayInfo'. I was able to figure this out when I started getting weird behavior on all the devices I plugged the Rift into.

Fortunately, going in and re-writing the feature report with the original values seems to have fixed at least some of my problems, but developers who are trying to bypass or extend the SDK should tread with caution.

Thanks for the warning. It sounds like we need a HID feature report backup utility to save these values so we can restore them if they get trashed. It sounds like you have already implemented most of just such a tool, used to repair yours. Care to share it?

This example was updated 7 months ago for "more robust handling of report length fields":
https://github.com/signal11/hidapi/blob/master/testgui/test.cpp

I used the hid-libusb version in my code:
https://github.com/signal11/hidapi/tree/master/linux
The hidraw drivers do not work in my linux mint VM, for some reason (but they work fine in kali linux).

"geekmaster" wrote:

"jherico" wrote:

The hidraw drivers do not work in my linux mint VM, for some reason (but they work fine in kali linux).

Is it a permissions problem? You might check the permissions on /dev/hidraw* and see what they say. I had to write a custom udev rule to make them accessible on my machine.

"jherico" wrote:

"geekmaster" wrote:

"jherico" wrote:

The hidraw drivers do not work in my linux mint VM, for some reason (but they work fine in kali linux).

Is it a permissions problem? You might check the permissions on /dev/hidraw* and see what they say. I had to write a custom udev rule to make them accessible on my machine.

You can read more details in nsb's "linux+c library" thread (early posts):
viewtopic.php?f=20&t=667#p6477
I did not try a custom udev rule, but instead switched to using the signal11 library myself (libusb version).

"geekmaster" wrote:
It sounds like we need a HID feature report backup utility to save these values so we can restore them if they get trashed. It sounds like you have already implemented most of just such a tool, used to repair yours. Care to share it?

I ultimately had to do it in Linux using my Java library. I've just pushed the Java code up to my Git repository at OculusSDK. The code I used to fix my rift is in the function

com.encom13.input.oculus.RiftTest.fixDisplayInfo(HIDDevice)

in the Java/src/test/java folder on the java Git branch. No guarantee that it will do the right thing on anyone else's machine. Many environments require custom udev rules, or running as root in order to execute the code.

"jherico" wrote:

"geekmaster" wrote:
It sounds like we need a HID feature report backup utility to save these values so we can restore them if they get trashed. It sounds like you have already implemented most of just such a tool, used to repair yours. Care to share it?

I ultimately had to do it in Linux using my Java library. I've just pushed the Java code up to my Git repository at OculusSDK. The code I used to fix my rift is in the function

com.encom13.input.oculus.RiftTest.fixDisplayInfo(HIDDevice)

in the Java/src/test/java folder on the java Git branch. No guarantee that it will do the right thing on anyone else's machine. Many environments require custom udev rules, or running as root in order to execute the code.

Thanks. Although you are probably the first, you may likely not be the last, to need a Rift "debricking" tool like that...
:o

That said, there might actually be something USEFUL we can do by writing to things that were "supposed" to be read-only. I love firmware "back doors" like this.
;)

"geekmaster" wrote:

That said, there might actually be something USEFUL we can do by writing to things that were "supposed" to be read-only. I love firmware "back doors" like this.
;)

Hmmm... reminds me of some old usenet posting (http://www.cgl.uwaterloo.ca/~smann/Humor/devil.txt), where a programmer faces off with the devil. In trying to solve the problem before the devil he's running out of memory and wires up his pocket watch to add that little extra. So that's what I imagine you doing with the writable displayInfo of the Rift. :P

jherico, thank-you for discovering this! This is the kind of nasty problem you can spend days debugging... especially if you're getting false positive feedback from some programs working fine because they're using hardcoded displayinfo.

"jherico" wrote:
... I accidentally trashed my Rift because the sample code for low level HID access on Linux (found here: http://lxr.free-electrons.com/source/samples/hidraw/hid-example.c ) writes to feature ID 9, which is what the Oculus uses for 'DisplayInfo'. ...

Now I am curious if any of the other signal11 demo code writes to feature reports. We will need to start watching for such activity before testing such code. Although I did not see such strange occurances, I want to see if my feature reports are returning correct values now, because I *did* run some signal11 demo code with my Rift (although a different app from what you reported).

"atavener" wrote:
jherico, thank-you for discovering this! This is the kind of nasty problem you can spend days debugging... especially if you're getting false positive feedback from some programs working fine because they're using hardcoded displayinfo.

Just before I posted my code, someone else already PM'd me asking about the symptoms and how I fixed it. Apparently they were able to use my tool to repair their Rift as well. I'll post something in the Community Support forum and try to massage up what I have so far into a full 'backup / restore' application that you can run from the command line.

"jherico" wrote:
I just discovered that the HID feature reports that should be read-only aren't. I accidentally trashed my Rift because the sample code for low level HID access on Linux (found here: http://lxr.free-electrons.com/source/samples/hidraw/hid-example.c ) writes to feature ID 9, which is what the Oculus uses for 'DisplayInfo'. I was able to figure this out when I started getting weird behavior on all the devices I plugged the Rift into.

Fortunately, going in and re-writing the feature report with the original values seems to have fixed at least some of my problems, but developers who are trying to bypass or extend the SDK should tread with caution.

Hmm... When I tried reading my feature report 9, I did a copy/paste FUBAR, and the code I copied did a SEND feature report instead of a get (with a zeroed buffer). So of course, the FIRST time that I read this report, it contains all zeros...

Anyway, I plan to write these values to my Rift:

cmd=0,dist=1,hres=1280,vres=800,hsize=149760,vsize=93600,vcent=46800,lenssep=63500,
eyetoscreen0=49800,eyetoscreen1=49800,K0=0.0,K1=0.0,K2=0.0,K3=0.0,K4=0.0,K5=0.0

I will write those to my newly zeroed Rift... Do they look about right?

It seems that with 56 bytes in that packet, if it only contains "standard" default values (apparently not writeable in early firmware), that report could use a new layout with a single bit telling the SDK to "use default values", and the rest of the packet could hold other compressed data.

"geekmaster" wrote:

cmd=0,dist=1,hres=1280,vres=800,hsize=149760,vsize=93600,vcent=46800,lenssep=63500,
eyetoscreen0=49800,eyetoscreen1=49800,K0=0.0,K1=0.0,K2=0.0,K3=0.0,K4=0.0,K5=0.0

I will write those to my newly zeroed Rift... Do they look about right?

I'm not certain. Ever since I 're-flashed' my Rift to correct a similar mistake, I've had the wrong distortion values. I've been meaning to get around to fixing them, but it hasn't been enough of a problem to actively work on it.

Have you considered re-applying the latest firmware? It seems like it's likely that that could actually reset the HID reports. Not sure if it will let you flash over the current version with the same version though.