Display to Huawei VR Glasses

Hey all!

I am trying to use a set of Huawei VR Glasses with an Xavier NX (link:Huawei VR Glass). They have an option cable that connects to the goggles with USB C, and has DisplayPort (1.2 and above) and 2 USB A ports (supposed to be 3, but they don’t have the extra pins I would expect) on the other side.

When I connected it to my fairly standard Windows 10 computer, it was detected as a 3200x1600 display with a 90hz refresh rate. I do get an image that is displayed in the goggles, they do some weird splitting on the image to display in each eye, but I get a normal image with no issues. Up to this point I hadn’t installed any drivers or Huawei software on the Windows machine, this should have been fairly stock.

When plugged into the Xavier NX they just didn’t display an image at all, they were detected in the NVIDIA X Server settings application, the resolution and refresh rate were also acquired properly. Another 70hz option also appeared, this makes sense since according to the limited information I can find about the headset tells me that it operated at 70hz when being run by a cell phone. I tried all combinations of settings to make them display an image or sign of life at all.

The only way that I could get them to display an image on the Xavier NX was to power them off of the Windows computer and originally connect the DP to it, then after I have an image in the displays I move the DP over to the Xavier NX without disconnecting anything else. At this point I do see the desktop background in the headset, but it is very broken, it appears that there are lines in the display that are shifted and they are changing fairly rapidly. This can be fixed by changing the refresh rate to 70hz, the image then becomes less broken, but still not perfect. If I then dial in some underscan in the NVIDIA X Server Settings app, the image fixes itself entirely.

As soon as I remove power from the headset I need to repeat the entire process for it to work again.

I know this sounds a bit weird, but I think I am just missing something simple since it worked on Windows straight out of the box. I do have a powered USB 3.0 hub on the way and an actual HDMI to DP converter to see if that will work.

Any suggestions?


1 Like

Not sure, I have no experience with these, but since you seem to have ruled out power issues, you may try to check if the read EDID is different when read after Windows config of the device or if just read from Xavier after power on of the VR glasses.
Try something like:

sudo find /sys -name 'edid'

and check the one for DP.

You may also add:

Option    "ModeDebug"

into device section of /etc/X11/xorg.conf, reboot and check from /var/log/Xorg.0.log what the nvidia X server think from your device modes available.

Yea, I figured that there would be no one with experience with this particular hardware, but I think it is a generic video driver issue.

I did try grabbing the EDID before and after being plugged into Windows, and just for fun I got it from windows itself. In all 3 cases they were the same. It was: EDID From Goggles - Pastebin.com.

I also added the “ModeDebug” to the configuration file, and didn’t see anything obviously wrong. But I’m not too familiar with it, so I have attached it here: Log From Bootup - Pastebin.com



You can use our system sys node to dump the edid.

  1. sudo cat /sys/kernel/debug/tegradc.X/edid #X=0,1,2.
  2. Share the full dmesg.

Sorry that somehow my network blocks pastebin. Could you directly attach it as a text file on forum? Thanks.

Here are the files Bootup Log.txt (24.6 KB) EDID.txt (767 Bytes)

I got the EDID from $ xrandr --props

After running it through a simple online EDID converter it does appear that it is valid and correct.

The log you are posting is not boot up log.

Please boot up your device and use command dmesg to dump the boot up kernel log.

Sorry, that was the log that @Honey_Patouceul recommended that I collect, the Xorg one.

Here is the Kernel Bootup Log.txt (86.2 KB)



If we only need to check DP, could you remove HDMI and share the dmesg and xorg.0.log again?

I rebooted the system with the goggles connected with DisplayPort and no monitor, After it booted up I connected with SSH to grab the log files.Kernal Bootup Log.txt (90.0 KB) Xorg Log.txt (20.0 KB)

Hope this helps!

It seems there is no error from both dmesg and xorg log. Thus, it has chance that we just don’t support this mode.

Need to check with internal team.

What is showing on your screen? Could yo share a video for it? I mean the problem you have.

It’s a bit hard to capture, but I have tried my best.

The issue is worse when the Jetson is set to 90hz (this was captured at 70hz).

But again I can only get an image when the goggles are connected to my Windows laptop first then transferred to the Jetson.



Sorry for late reply. Could you also provide which software version are you using?

Also, does this issue only happen to ubutnu desktop? or even other application?

We need these info.

1). Please dump out the following nodes when the flickering occurs so that we can get more information on the state of display:

  • /sys/kernel/debug/tegradc.1/regs
  • /sys/kernel/debug/tegradc.1/stats
  • /sys/kernel/debug/tegradc.1/mode
  • /sys/kernel/debug/tegradc.1/sor/regs
  • /sys/kernel/debug/bpmp/debug/clk/clk_tree

2). Also perform the following experiment as well:

  1. Stop/kill X11.

  2. echo 4 > /sys/class/graphics/fb1/blank

  3. echo “mode” > /sys/class/graphics/fb1/mode

  4. “mode” should be one of the chosen 70/90Hz modes from /sys/class/graphics/fb1/modes (note the plural "mode s " here)

  5. echo 0 > /sys/class/graphics/fb1/blank

  6. echo 0xffff0000 > /sys/kernel/debug/tegradc.1/background

  7. This should force display to output a solid blue background color.

If the above experiment shows no screen tearing/corruption, then it at least confirms that the underlying display pipeline is setup correctly, and we should probably focus more on the X11 stack (the ubuntu desktop).

I have attached all the logs you requested. mode.txt (236 Bytes) sor_regs.txt (6.0 KB) stats.txt (34 Bytes) regs.txt (5.1 KB)

I also tried the experiment, and I got absolutely nothing displayed after I killed the X server. I tried both of the refresh rates to no avail.

I have also tried it on a totally separate computer running ubuntu 20.04, and it worked directly out of the box with no settings changes required. So it appears it is a jetson related issue.

My version of software is R32 (release), REVISION: 5.1, GCID: 26202423, BOARD: t186ref, EABI: aarch64, DATE: Fri Feb 19 16:50:29 UTC 2021

What we want to clarify is whether this issue is display kernel or X11 stack. Both of them are nvidia driver but just one from kernel while another one is the userspace graphic lib.

Please share me you whole steps in that test and also dmesg. You can also try to use some gstreamer app before step (6) and make sure there is really something rendering on your monitor.

Such gstreamer pipeline could be like below

gst-launch-1.0 videotestsrc ! video/x-raw,format=I420 ! nvoverlaysink

Also, the step to kill X is below command

sudo systemctl stop gdm
sudo loginctl terminate-seat seat0

And just to know what is the expected result here.

  1. Stop/kill X11.

This would stop the ubuntu desktop

  1. echo 4 > /sys/class/graphics/fb1/blank

This would totally blank the monitor. Even the backlight would be off.

For 3,4 if you check the fb1/mode is the mode you want to use, then no need to do anything here.
If it is not, check “modes” and pick the mode you want and echo it to “mode”.

  1. echo 0 > /sys/class/graphics/fb1/blank

This step would enable the display again. But since you disable the desktop, it should just light up the backlight with black screen.

Before doing 6, you can try my gstreamer pipeline from previous comment and see if anything rendering over screen.

My exact steps are as follows:

  1. Plug headset USB ports in to powered USB hub attached to Jetson
  2. Plug headset DP into laptop to enable headset (still not sure why this is needed)
  3. Plug headset DP into Jetson and power up (with no HDMI connected)
  4. Once I see the desktop in the headset (with lots of tearing)
  5. Connect to Jetson through SSH
  6. Drop into a SU terminal
  7. Kill X with the command you gave
  8. Run “echo 4 > /sys/class/graphics/fb1/blank”
  9. Run “echo “D:3200x1600p-89” > /sys/class/graphics/fb1/mode”. By default it is “U:3200x1600p-89”
    10: Run “echo 0 > /sys/class/graphics/fb1/blank”
  10. The backlight in the headset does now turn on
  11. Run the GStreamer example command, nothing is displayed.
  12. Run “echo 0xffff0000 > /sys/kernel/debug/tegradc.1/background”, nothing is displayed
  13. Reboot the Jetson and repeat steps 4-13 but with mode as “D:3200x1600p-70”, also never getting an image

Here is the dmesg log after the whole process: dmesg log.txt (96.2 KB)

Thanks for taking a look!

What if you don’t do step 9 ?

I have some typo in previous comment. What I wanted to say is if you think that mode is fine, then nothing need to do. Don’t need to change the mode.

That is why I asked what would happen if you don’t do step 9

I tried all the same steps except 9, and sadly got the exact same results.

One thing I noticed is that after running the GStreamer command I get the error message “nvbuf_utils: Could not get EGL display connection” This does happen weather I do step 9 or not.