[Linux][VR]How to place window on DISPLAY 0.1?

Development Platform & Builds
, , , ,
1

I used nvidia-settings to edit my X11/xorg.conf such that I have two screens: My primary monitor at DISPLAY 0.0 (1080p, 144 Hz), and my DK2 at DISPLAY 0.1. This works perfectly when I:

DISPLAY=:0.1 /usr/local/bin/OculusWorldDemo

There’s no judder, the scene isn’t vsync’d to the primary monitor, it’s great!

I’ve made some changes to the 4.8 branch of UE4, mostly following amigo’s changes for 4.7, and I can get a rotated window with a distorted stereo image to show up at the right edge of my primary monitor and the content of window responds to the rotation of the HMD. (Side note: there is a large black rectangle in the middle of the left eye view in this Window. I suspect this is a separate problem).

Instead of showing up on the right of the primary monitor, I would like this window to show up on the second screen, on DISPLAY 0.1. How can I find this display? Or, more correctly, how can I find the display containing the rift?

Additional info:

-When I have the rift as an extended part of the first screen (i.e., at position x= +1920 on DISPLAY 0.0) then HMDLog reports that it found the rift at position 1920,0. When I have the rift on the second screen, as I would like, then HMDLog reports that it found the rift at position 0,0 with no mention of the screen.

-When I have the rift as an extended part of the first screen, then the window gets placed in the rift but it looks entirely wrong. The viewports are cropped and misaligned.

-Reading the code, I’ve drilled down from the Preview in VR button to the creation of the PieWindow in Engine/Source/Editor/UnrealEd/Private/PlayLevel.cpp, and a few lines below that is the creation of the PieViewportWidget. Unfortunately this code uses slate-specific macros that I don’t understand so I can only guess that SNew( SWindow ) ends up calling SWindow::Construct, but I can’t be sure. If I’m correct, then I think the call to GetDisplayMetrics is part of what I am interested in. That seems to be platform specific; the Linux version can be found here. Therein, it uses SDL to get info about the monitors, and it does seem to enumerate the displays. I will play around with SDL to see how it represents multiple screens, and to see if the GetDisplayMetrics captures that properly.

Also, I’m slightly worried that I’m just reading the code about the mirrored preview, as happens in Windows when the HMD direct mode. Can someone verify that this code path I’m heading down is indeed for the window that should be displayed in the HMD?

2

There’s no support for virtual displays (as implemented on Linux) in UE. At some point we will add this by representing them as additional monitors (which is in line with the virtual dsiplays on other platforms - e.g. Spaces).

3

I find it a little bit dismissive that this answer was auto-marked as ‘accepted’. It certainly does not answer my question.

Is what I’m talking about really considered a ‘virtual display’? It is a physical display, just configured to use a separate X screen.

I’m willing to put in the work to get this working on my machine, and I’ll do a pull request if/when I get something working, but a little guidance would help. Am I even on the right track?

4

I’ve been playing around with SDL2. When my DK2 is on a separate X display, SDL_GetDisplayBounds returns x=0, y=0, w=1080, h=1920. When it is part of the main display everything is the same except x=1920 (as my primary monitor has a w=1920).
It seems that there is no way to get SDL_CreateWindow to create a window on a secondary display. Adding an x-offset to place the window where it WOULD be in extended mode simply places the window at the right edge of the first display, which is what I observed in UE4Editor.
It might be necessary to create the window first using OpenGL then to use SDL_CreateWindowFrom, but then I wonder if SDL is even necessary anymore?

5

Ah, sorry, I mistook it for virtual desktops. There’s no support for placing windows on a separate X screen either. That perhaps requires some changes in SDL as well (as you note above). Feel free to submit a pull request if you make it work, but please remember that things should remain cross-compilable without presence of X headers.

6

I posted a related question on the SDL board a few weeks ago but no replies. I will come back to this in the future.