bino2.1 with QVR opens 2 windows different sizes on screen, on wrong screen

[63n]

bino2.1 compiled with libQVR and VRPN on linux. Run ok. I'm exploring VR modes for a CAVE.

when a movie is played with the following QVR config, 2 windows open, but the right one is a little larger. I'd expect them to be the same size. There's 2 x 4K screens. The '2nd screen' is on the left, so the primary screen starts at (3840,0) instead of (0,0).

The 2 windows pop-up on the primary screen (wrong). To get the size right I might have to make the screen dpi's the same (the screens are not actually the same physical size: it's a laptop screen, with an external monitor on the left). However, both 200x200 windows are on the same (wrong) screen, so i'd still expect them the same size.

Config file is based on an example config file from the libQVR examples.

observer o0
    navigation wasdqe
    tracking custom

process main
    ## ipc tcp-socket
    ipc local-socket
    ## ipc shared-memory
    window 0
        observer o0
        position 1500 100
        size 200 200
        screen_is_fixed_to_observer false
        screen_is_given_by_center false
        screen_wall  0 -1 -10  2 -1 -10  0 +1 -10
        
process child
    launcher ssh localhost env LD_LIBRARY_PATH=/opt/bino/lib
    display :0.0
    window 1
        observer o0
        position 1700 100
        size 200 200
        screen_is_fixed_to_observer false
        screen_is_given_by_center false
        screen_wall  -2 -1 -10  0 -1 -10  -2 +1 -10

Command with firehose debug output shows:

 $ bino --vr --qvr-config=/home/ben/da/dev/qvr/configs/2-process-ssh.localhost.qvr --qvr-log-level=firehose ~/Movies/myMovie.mp4

QVR[0]: starting IPC server
QVR[0]: launching child process child (index 1) ...
QVR[0]: waiting for child processes to connect to main ...
QVR[1]: child process child (index 1) connecting to main ...
QVR[1]: connected to local server /tmp/qvr-91a9c67f-465e-4d85-b683-2623f4a984b0
QVR[1]: ... done
QVR[1]: child process child (index 1) waiting for init command from main ...
QVR[0]: client with process index 1 connected
QVR[0]: ... all clients connected
QVR[0]: initializing child processes with 204 bytes of static application data
QVR[0]: process main (index 0) uses default display which has 2 screens, default screen is 0
QVR[0]:   screen 0: size 0.382x0.215 meters, geometry x=3840 y=0 w=2194 h=1234
QVR[0]:   screen 1: size 0.597x0.336 meters, geometry x=0 y=0 w=2194 h=1234
QVR[0]: process main (index 0) creating 1 windows
QVR[0]:   main window...
QVR[1]: ... done
QVR[1]: initializing child process child (index 1) ...
QVR[1]: ... done
QVR[1]: process child (index 1) uses display :0.0 which has 2 screens, default screen is 0
QVR[1]:   screen 0: size 0.382x0.215 meters, geometry x=3840 y=0 w=1993 h=1121
QVR[1]:   screen 1: size 0.597x0.336 meters, geometry x=0 y=0 w=1993 h=1121
QVR[1]: process child (index 1) creating 1 windows
QVR[1]:   main window...
QVR[1]:     context is OpenGL 3.3 core profile
QVR[0]:     context is OpenGL 3.3 core profile
QVR[1]:     OpenGL version:    3.3.0 NVIDIA 470.239.06
QVR[1]:     OpenGL SL version: 3.30 NVIDIA via Cg compiler
QVR[1]:     OpenGL vendor:     NVIDIA Corporation
QVR[1]:     OpenGL renderer:   NVIDIA GeForce GTX 1080/PCIe/SSE2
QVR[0]:     OpenGL version:    3.3.0 NVIDIA 470.239.06
QVR[0]:     OpenGL SL version: 3.30 NVIDIA via Cg compiler
QVR[0]:     OpenGL vendor:     NVIDIA Corporation
QVR[0]:     OpenGL renderer:   NVIDIA GeForce GTX 1080/PCIe/SSE2
QVR[1]:   window 0...
QVR[0]:   window 0...
QVR[1]:     context is OpenGL 3.3 core profile
QVR[0]:     context is OpenGL 3.3 core profile
QVR[1]:     OpenGL version:    3.3.0 NVIDIA 470.239.06
QVR[1]:     OpenGL SL version: 3.30 NVIDIA via Cg compiler
QVR[1]:     OpenGL vendor:     NVIDIA Corporation
QVR[1]:     OpenGL renderer:   NVIDIA GeForce GTX 1080/PCIe/SSE2
QVR[0]:     OpenGL version:    3.3.0 NVIDIA 470.239.06
QVR[0]:     OpenGL SL version: 3.30 NVIDIA via Cg compiler
QVR[0]:     OpenGL vendor:     NVIDIA Corporation
QVR[0]:     OpenGL renderer:   NVIDIA GeForce GTX 1080/PCIe/SSE2
QVR[1]:     creating window 1...
QVR[1]:       screen: 0
QVR[1]:       position 1700,100 size 200x200
QVR[1]:     ... done
QVR[0]:     creating window 0...
QVR[0]:       screen: 0
QVR[0]:       position 1500,100 size 200x200
QVR[0]:     ... done
QVR[0]: mainLoop() ...
QVR[0]:   ... updating observer 0
QVR[0]:   ... sending wasdqe state (9 bytes) to child processes
QVR[0]:   ... sending observer 0 (228 bytes) to child processes
QVR[0]:   ... sending dynamic application data (2 bytes) to child processes
QVR[0]:   ... rendering commands are on their way
QVR[0]:   render() ...
QVR[0]:   ... preRenderProcess()
QVR[0]:   ... preRenderWindow(0)
QVR[0]:   ... render(0)
QVR[0]:   ... view 0 frustum: l=-0 r=0.01 b=-0.01305 t=-0.00305 n=0.05 f=100
QVR[0]:   ... view 0 viewmatrix: [1 0 0 0] [0 1 0 -1.61] [0 0 1 0] [0 0 0 1]
QVR[1]:   ... got command 'wasdqestate' from main
QVR[1]:   ... got command 'observer' from main
QVR[1]:   ... got command 'render' from main
QVR[1]:   render() ...
QVR[1]:   ... preRenderProcess()
QVR[1]:   ... preRenderWindow(0)
QVR[1]:   ... render(0)
QVR[1]:   ... view 0 frustum: l=-0.01 r=0 b=-0.01305 t=-0.00305 n=0.05 f=100
QVR[1]:   ... view 0 viewmatrix: [1 0 0 0] [0 1 0 -1.61] [0 0 1 0] [0 0 0 1]
QVR[0]:   ... postRenderWindow(0)
QVR[0]:   ... postRenderProcess()
QVR[0]:   ... renderToScreen(0)
QVR[0]:   ... asyncSwapBuffers(0)
QVR[0]:   ... event processing
QVR[0]:   ... app update
QVR[0]:   ... waiting for buffer swap 0...
QVR[0]:   ... buffer swap 0 done.
QVR[0]:   ... waiting for children to sync
QVR[1]:   ... postRenderWindow(0)
QVR[1]:   ... postRenderProcess()
QVR[1]:   ... renderToScreen(0)
QVR[1]:   ... asyncSwapBuffers(0)
QVR[1]:   ... waiting for buffer swap 0...
QVR[1]:   ... buffer swap 0 done.
QVR[1]:   ... sending command 'sync' with 0 events in 0 bytes to main
:

[63n]

Screenshot (top right corner of right screen)

[63n]

Apologies. Seems the additional config setting: display_screen 1 will put the 2 windows on the "other" screen.. Nb it seems the Screen (x,y) position is relative to each screen. ie. There's two (0,0) locations - one per display_screen - the coords do not span the total X11 display. There's more info on the config syntax & usage here: https://marlam.de/qvr/libqvr-reference/

[63n]

xrandr reports for these 2 screens:

Screen 0: minimum 8 x 8, current 7680 x 2160, maximum 32767 x 32767
HDMI-0 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
DP-0 connected primary 3840x2160+3840+0 (normal left inverted right x axis y axis) 382mm x 215mm

The code section which reports the screen width is in: libqvr/manager.cpp

    for (int i = 0; i < QVRScreenCount; i++) {
        QVR_INFO("  screen %d: size %gx%g meters, geometry x=%d y=%d w=%d h=%d", i,
                QVRScreenSizes[i].width(), QVRScreenSizes[i].height(),
                QVRScreenGeometries[i].x(), QVRScreenGeometries[i].y(),
                QVRScreenGeometries[i].width(), QVRScreenGeometries[i].height());
    } 

I guess I'm expecting 200 pixels to not be scaled by screen size. Moreso, it seems odd (bug?) one window is a different size.

[63n]

OMG. Looks messy.. Apologies if this is not the place for discussion. I've discovered: https://doc.qt.io/qt-5/highdpi.html https://doc.qt.io/qt-6/highdpi.html trying these didn't help much

export QT_USE_PHYSICAL_DPI=0
export QT_ENABLE_HIGHDPI_SCALING=0

but this brought the windows closer in size. The window coming from the ssh launch is still a different size. export QT_SCREEN_SCALE_FACTORS="2;1"

[63n]

aha.. Looking at system settings (Linux KDE Plasma 5) there is a system global scaling setting 175% reducing this to 100% (not necessarily my on-going preference, but worth changing to explore the issue) Then run the test again, and lo - the windows are the same right size. Going forward, I'd think I'd prefer not to change the Global Scaling (though this was set a long time ago, when Plasma was still settling-in. Perhaps it is time to reset everything back to 100% ??). It's still curious one window was a different size. Ideally, I think I'd prefer to find an environment variable to set, to turn off scaling for bino (only) inside a wrapper.

[63n]

Also, when i Ctrl+C the process in the bash shell, the local process stops, but the process started via a ssh stays running. It has to be killed. Passing ESC into either window closes both. sorry different issue.

[63n]

Aha! This overrides the 175% scaling. export QT_ENABLE_HIGHDPI_SCALING=100 Well. It makes the windows the same size. They're both bigger than 200 pixels though!

[marlam]

I'm not sure what I can do about that. LibQVR passes the configuration values (size, position etc) directly to Qt. At this point, a lot of different mechanisms may influence the result: Qt HighDPI support, Qt scaling options, window manager settings, X11 options via xrandr, and so on. It may make sense to try with a very basic window manager (not Gnome or KDE or whatever, just something plain and simple) to make sure that the desktop environment does not mess with any of this.

[marlam]

I just tested VR multi-window / multi-process mode on X11 and Wayland under the Plasma desktop environment. On X11, I get the expected window placement and sizing behavior. On Wayland, with the same binaries, I first had to disable the 175% scaling too (I did this in the display configuration dialogue). After that, the placement and size was not the one specified by QVR. It seems either Wayland prohibits explicit window sizing and positioning, or Plasma does not yet implement that on Wayland. Either way, for now I must still recommend running in X11 for this kind of setup. I will of course regularly test on Wayland in the future.