Jetson / Oculus DK2

Is anyone out there successfully driving a DK2 from a Jetson? If so, would you mind sharing how?

We have a DK1 working fine with the Jetson, using our own home-grown telemetry/sensor fusion code which uses libusb to get the head tracking data.

when we switch to the DK2, we get no HDMI output to the DK2, just a black screen and an apparent DK2 error code of alternating orange - blue led blink, with every 6th orange light a few milliseconds longer than the others.

The DK2 works fine with a desktop ubuntu system, and also with windows. We extracted the EDID info on that working system, built a binary EDID, tried to point to it in xorg.conf, but no joy. We also tried cvt/xrandr to set the parameters but again no luck.

The windows side information (from moninfo.exe) is:

Signature="WINDOWS NT"











;Base EDID





;YourColorProfileFile.icm for non-sRGB displays

MFG=“EnTech Taiwan”
DISC=“Monitor EDID Override Installation Disk”
PRODUCTID=“OVR Rift DK2 (OVR0003 EDID Override)”

We used the ASCII edid to create a binary EDID file, then changed /etc/X11/xorg.conf.jetson-tk1 to
point at it:

Section “Module”
Disable “dri”
SubSection “extmod”
Option “omit xfree86-dga”

Section “Device”
Identifier “Tegra0”
Driver “nvidia”

Section “Screen”
Option “CustomEDID” “DSI-0:/etc/X11/dk2EDID.bin”

Section “Monitor”
Identifier “DSI-0”

Option “Ignore”


On the ubuntu system where the dk2 works we tried get-edid | parse-edid, but it barfs on the edid extension block reported by the dk2.

The xrandr attempt was:

cvt 1080 1920 75

which returns:

1080x1920 74.98 Hz (CVT) hsync: 150.40 kHz; pclk: 225.00 MHz

Modeline “1080x1920_75.00” 225.00 1080 1176 1288 1496 1920 1923 1933 2006 -hsync +vsync

xrandr --newmode “1080x1920_75.00” 225.00 1080 1176 1288 1496 1920 1923 1933 2006 -hsync +vsync

xrandr --addmode DSI-0 “1080x1920_75.00”

after this, xrandr -q shows:
default connected 1920x1200+0+0 0mm x 0mm
1920x1200 60.0*
1920x1080_75.00 74.9
1080x1920_75.00 (0x50) 225.0MHz
h: width 1080 start 1176 end 1288 total 1496 skew 0 clock 150.4KHz
v: height 1920 start 1923 end 1933 total 2006 clock 75.0Hz

not sure where the “default” comes from, and why it’s not DSI-0 as in the xorg.conf file

anyway, if you’re here, thanks for reading and any insights would be appreciated


I’ve seen cases where people had a monitor fail the edid tools due to extension parse errors like this…was there an email address given to report this during the edid parse failure? There’s a very good chance that the code used in parse-edid is the same as the code used in the actual X11 server and that sending the information to the email address would get both fixed quickly. Last time I saw this it was fixed within about 3 days of reporting it.

Thanks for the reply.

yes, there was an email address and request to hear about it as long as it wasn’t a tv.
we did email, with stdout and stderr attached but no luck there either.
Here, ‘we’ != ‘me’, so I don’t remember whether there was no
reply or a one that left the question open. I’m pretty sure it was the latter, but I’m absolutely
sure we did contact him.

In any case, we used the ASCII edid reported on the Windows side to generate the binary (though we’re trusting it is correct of course).

I haven’t tested this yet, but I learned recently from a team who works with Oculus, that 0.3.1 was the last Oculus SDK not to ship a binary version of LibOVR. More recent versions come with header files and pre-compiled binaries of libovr.o, but not for armhf architecture, only for x86 and possibly x86-64.

I have successfully compiled the Rift Ubuntu SDK (0.4.4) and is running perfectly fine on the TK1. However, I also got a black screen, though no blinking LED (which I believe is due to wrong resolution setup) - the LED is constantly orange (except from when just plugged in). The TK1 detects the Rift-display just fine and the resolution/orientation is fine (seen through remote desktop).
Not really sure what else to try at this point…

Hi Rick and Lidegaard,

This is kind of a challenging issue involving EDIDs, xrandr,…especially if you want to get HMD mode working. DK1 still matches a lot of the HDMI standards; DK2 is a little funky versus conventional hardware. That’s what happens when you build and ship a new manner of interacting with computers.

I’ve confirmed that we’ve done the requisite work to enable kernel support for DK2’s ‘interesting’ hardware mash-up. I’m now investigating how we can help the community in this regard.


Lidegaard, Barrett,

We created the xorg.conf.jetson-tk1 file below based on data from
xrandr --verbose, read-edid|parse edid, and cvt on the machine where the dk2 works fine:

Copyright © 2011-2014 NVIDIA CORPORATION. All Rights Reserved.

This is the minimal configuration necessary to use the Tegra driver.

Please refer to the xorg.conf man page for more configuration

options provided by the X server, including display-related options

provided by RandR 1.2 and higher.

Disable extensions not useful on Tegra.

Section “Module”
Disable “dri”
SubSection “extmod”
Option “omit xfree86-dga”

Section “Device”
Identifier “Tegra0”
Driver “nvidia”
Option “UseEDID” “FALSE”
Option “IgnoreEDID” “true”

Section “Monitor”
Identifier “DSI-0”
Option “Ignore”

Section “Monitor”
Identifier “Rift DK2”
ModelName “Rift DK2”
VendorName “OVR”
Option “UseEDID” “false”
Option “AllowEmptyInitialConfiguration”
Option “IgnoreEDID” “true”
# Monitor Manufactured week 10 of 2014
# EDID version 1.3
# Digital Display
DisplaySize 1080 1920
Gamma 2.20
Option “DPMS” “true”
Horizsync 30-150
VertRefresh 56-77
# Maximum pixel clock is 170MHz
#Modeline “1080x1920_75.00” 224.85 1080 1168 1288 1496 1920 1921 1924 2004 -HSync +Vsync
Modeline “Mode 1” 224.85 1080 1168 1288 1496 1920 1921 1924 2004 -HSync +Vsync
Option “PreferredMode” “Mode 1”

Section “Screen”
Identifier “Default Screen”
Monitor “Rift DK2”
Device “Tegra0”
Defaultdepth 24
SubSection “Display”
Depth 24
Virtual 1080 1920

When I boot, the 1080x1920 resolution shows up as an option, but it not marked as the ‘current’ choice.
I ran a script from /etc/lightdm which waited a few seconds, used xrandr to manually select the correct resolution, waited a few more seconds, then captured xrandr --verbose again. It seems like it
is correct and selected:

ConnectorType: HDMI
640x480 (0x18d) 25.2MHz +HSync +VSync +preferred
h: width 640 start 656 end 752 total 800 skew 0 clock 31.5KHz
v: height 480 start 490 end 492 total 525 clock 60.0Hz
1080x1920 (0x18e) 165.0MHz +HSync +VSync *current
h: width 1080 start 1113 end 1123 total 1138 skew 0 clock 145.0KHz
v: height 1920 start 1922 end 1928 total 1933 clock 75.0Hz
1080x1920 (0x18f) 158.4MHz +HSync +VSync
h: width 1080 start 1113 end 1123 total 1138 skew 0 clock 139.2KHz
v: height 1920 start 1922 end 1928 total 1933 clock 72.0Hz
1080x1920 (0x190) 132.0MHz +HSync +VSync
h: width 1080 start 1113 end 1123 total 1138 skew 0 clock 116.0KHz
v: height 1920 start 1922 end 1928 total 1933 clock 60.0Hz
1080x948 (0x191) 132.7MHz +HSync +VSync
h: width 1080 start 1113 end 1123 total 1138 skew 0 clock 116.6KHz
v: height 948 start 960 end 966 total 972 clock 120.0Hz

… but still no luck - the evil LED keeps blinking.

While the syntax and options complexity of x11/edid/xrandr always leaves me feeling that there is some idiosyncratic thing I just don’t get, at this point it is starting to feel like maybe it is a kernel issue.

We’re putting a $500USD bounty on the problem in the hopes that it is a configuration thing that somebody
who has fought this fight before could solve, since we can’t spend anymore time on it.

I’ll post it here if we learn anything new.

Closure finally achieved… We got a dk2 for Santyago, and he solved the issue (pixel clock rate problem). Support is included in the latest grinch release (21.3.1).

Big thanks also for NVIDIA, who helped solve found problem! :)

Awesome! Great work! :-)

Hi Santyago,

Is it possible to update the kernel from 19.3 (one of your first Grinch versions) to 21.3.2 without re-flashing the TK1 (as I have some stuff I would like to avoid having to install again)? Or would you recommend a fresh flash?

Many thanks in advance and keep up the great work!!

If you are using u-boot, I think it should work. If not, within 2-3 days will be the Grinch 19.3.9

Okay great, thanks again!


I’m using the Grinch 21.3.4 for Jetson TK1 with the Rift DK2. The display is on and working on the Rift (1080x1920), however the orientation is incorrect: it’s “normal” and not rotated 90 degrees, hence cannot be used. If I try to rotate it either clock- or anticlockwise I get a blue screen and nothing works after this and a reboot is required!
Anybody else got this problem or a possible solution?

Many thanks in advance!