Nreal Airs - DRM Mode / cropping bug / low hz / investigation

Hey iam currently trying to solve an issue with the nreal air glasses combined with the steamdeck in gamemode (not desktop mode) and found out some infos that could help to fix it.

Problem: in gamemode steamde k regognize the nreal air in a strange way that prevent the display from receiving all frame constantly. Its like the display only runs at 30hz and 30fps.

Workaround: i managed to get it somehow fixed by allowing the steamdeck to run the nreal airs with 112 hz and 56fps. The 112hz are not correct for sure, but it works around the faulty identification. It should be in reality 56hz.

Then i found an entry that allow to change the drm mode for displays. Standard was “fixed” and i changed it to “cvt” that allowed me to rund 120hz (60hz real) and 60fps constant but, and now it gets interesting…the problem with the cropping 10% of the top part gets displayed at the bottem kicks in.

So my question is now. Do the nreal airs have any specific drm mode, they should run? I found a lot of different ones, but i dont want to test them all…

1 Like

Hi developer. Thanks for using our products. If you use Steam Deck with Air, the glass should work as a monitor, there should be no DRM limit.
And I wondered if you don’t change it to ‘CVT’, Air can work at 60fps?

Standard DRM mode is “fixed”
I tested some new stuff and i got it to work with 57hz and 57fps stable now and without the cropping issue from cvt.

I think it has something to do with the way vsync is handled by the steamdeck.

What i dont understand is, whats so different about those panels from the airs? It looks like, the panels can drive a much bigger resolution, when the cropping issue was present, i could see a bigger hight than in native full hd. Is the panel actually 16:10 or even bigger?

I also made in work in native 60hz/60 fps by changing the nested-refresh in gamescope running at 63. I cant tell why it works with this setting, but i think its somehow related to vsync handling by steamdeck and a faulty display recognition. I can see how steamdeck in gamemode actually recognize the specs of the glasses yet, but i try to find a way.

1 Like

Cool, thanks for testing so many ways and sharing this info. We will also try to find a better solution for steamdeck when it arrives our office.

1 Like

You can replicate the same vsync issue with the currently available HDMI to USB-C adapters (e.g. the Goovis Young HMD adapter). HDMI signals also get garbled in the exact same way as stated by @dominguez:

  1. At the top of the screen, content begins around 5% (so the top 5% is cut off)
  2. After the content end, there’s a roughly same height area as the cut off bit, where the last line is repeated (resulting in a weird blur)
  3. Below that, the top 10% of the screen is repeated

I have to agree with @dominguez, the displays in the Air do seem to be 1920x1200 (or, roughly 10% larger) than the officially stated 1920x1080. A vsync issue that would happen at the transcoding of the HDMI signal to the displays’ native protocol would actually make sense here.

I’m 99% sure that this could be fixed in firmware, and if you unlocked that extra 10% screen height, that would be even better. Also, you know, if you open sourced the firmware of the Air, there’s a number of users who would gladly help fixing these issues :slight_smile: Even if we have to sign an NDA and not release the sources to others.

1 Like

Thanks for also giving some input on this topic. For some reason i dont get the bug with the cropping issue with my hdmi to usb c adapter connection. But yesterday u managed to force this bug on my desktop pc by editing the display setting through nvidia custom resolution tool. If i switch the drm mode i get the same result USB C or Hdmi and for dome reason i cannot turn it back to original without deleting the display manually in windows…

Which HDMI adapter are you using exactly?

I used this one, but another user also bought this, and it didnt dolve the issue. Our best guess after testing was a difference in firmware version. But i couldnt read my version out. It only told be unkown.

USB C auf HDMI Adapter 4K 60Hz, Dockteck Thunderbolt 3 iPad/MacBook HDMI Adapter, für MacBook Pro/Air M1, iPad Pro/Air 4, Samsung Galaxy S20/S10, Surface Pro 7, XPS 13/15, Huawei und mehr -Aluminium https://amzn.eu/d/2Fnpyfr

Okay, but how are you plugging this into the glasses? This converts an USB-C output to HDMI, not the other way around.

Oh sry got the wrong link, i think its out of stock and didnt show up anymore. Here you go

HDMI Stecker auf USB-C Buchse mit Micro-USB Kabel, HDMI-Eingang auf USB Typ C 3.1-Ausgang konverter, 4K 60 Hz Thunderbolt 3-Adapter für MacBook Pro,Mac Air,Microsoft Surface https://amzn.eu/d/9lVs77A

Ah awesome. I have the same adapter, but it results in the issue detailed above.

According to your attempts to fix things, it seems to be a framerate negotiation issue - when set to 63Hz, you’re getting proper 60Hz without any distortion.

You also mention that it’s possibly a firmware version difference. I will check around to see if there’s an older Nebula APK with an older firmware available, and maybe even possible to downgrade.

@nreal-dev this is precisely where open sourcing the firmware would benefit both Nreal, and the community. You guys have limited resources, and need to focus on business critical things - and having the glasses work with random HDMI adapters is not on top of the list, understandably. But for example, Android itself evolved because of the open source community - features that weren’t pressing for Google’s core team got developed by third parties, and slowly made their way to being integrated into AOSP. The same principle would work here as well.

Hey there, you need to separate the two issues here, even if they are somewhat related to each other.

One issue appears by using hdmi adapter amd results into the cropping issues for most users (dont happens for my unit)

And the issue with the steamdeck combined with airs in gamemode, results into an 30hz/fps lock if you dont edit the gamescope-session file with hard coded 63 refresh.

The DRM Mode CVT change can replicate the issue, most people habe with their Glasses used in combination with an HDMI Adapter. But this was only mentioned for testing and bug investigation. It only shows, that the glasses are not recognized correct on some devices or adapter combinations and perhaps run in a wrong DRM Mode. Since DRM can have a lot of different informations, i think this is the cause of most issues mentioned here.

I totally agree wirh your idea to open up the development, because it will improve the speed of optimising and also help to get more use out of this product.

1 Like

I don’t think the two issues are separate, at all.

The cropping issue is actually related to signal sync issues - specifically, the blanking/backporch/frontporch values coded in the EDID information does not work for HDMI signal for some reason.

Changing DRM configuration would also result in a change of the signal timings, which explains why you’re getting the “cropping” simply by changing the DRM mode.

What I think is happening here, is that the displays used in the Air are actually 1920x1200, and the video signal decoder MCU has a very specific set of supported signal timing profiles, and HDMI (or DRM, or custom framerate) throws a wrench in the machine.

1 Like

That is correct, the problems are linked, but i wanted to make sure, that while testing, its two seperate things to consider. You theorie about the edid interpretation sounds like my best bet too. Whatvi dont get is, why steamdeck desktop mode with x11 display protocol, gets it right, but wayland has problems to identify the configuration.

Because they’re different implementations.

The desktop mode on the Steam Deck uses an off-the-shelf desktop (and therein, screen) management system. But the game mode compositor is completely custom made by Steam, and it’s quite possible some things were overlooked (especially if we get into the “quirks” territory of screen handling, where X has the upper edge, due to the protocol being around for nearly 40 years, and its Linux implementation turning 18 this year. Wayland was written from the grounds up, taking into account a lot of existing scenarios, but not all of the edge cases).

Hey nreal, you wanted to put out some infos about that after testing this problem with your steamdeck. Any news on that?

Hi, we did test the device with Air. And currently, we are discussing the solution internally. Please give us some more time.