wayland: regression with imgui-rebased ( https://github.com/dhewm/dhewm3/pull/576 )

[j4reporting]

found easy procedure to crash dhewm3 on linux with wayland ( didn´t test with x11)

wayland/gnome
desktop resolution 2560x1440@144z (nvidia driver 555.58.02 )

SDL_VIDEODRIVER=x11 // no problem with SDL_VIDEODRIVER=wayland
with X11 the resolution used by SDL changes to desktop resolution

r_fullscreenDesktop = "0"
r_fullscreen = "0"

r_mode = "-1" 
r_customHeight = "1080"
r_customWidth = "1920"

works with dhewm 1.5.3

several ways to reproduce

1. in main screen
   alt/enter to fullscreen
   alt/enter to window -> crash

2. in main screen
   alt/enter to fullscreen
   open imgui
   select video tab -> crash

3. in main screen
   open imgui/video
   change from Windowed to Fullscreen
   apply -> crash

bt is not very useful, need to get libbacktrace and recompile

----- Initializing Session -----
in_grabKeyboard: Will *not* grab the keyboard if mouse is grabbed, so global keyboard-shortcuts (like Alt-Tab) will still work
----- Game Map Shutdown -----
'vid_restart partial' succeeded in changing resolution and/or fullscreen mode
dhewm3: /home/markus/src/github/doom3/dhewm3-imgui/neo/sys/glimp.cpp:749: glimpParms_t GLimp_GetCurState(): Assertion `ret.width == glConfig.winWidth && ret.height == glConfig.winHeight' failed.


Looks like dhewm3 1.5.4pre crashed with signal SIGABRT (6) - sorry!

dhewm 1.5.3 switches seamlessly to full screen 2560x1440 and back to the configured resolution in windowed mode.

]r_fullscreen 1
]vid_restart 
Shutting down sound hardware
Shutting down OpenGL subsystem
----- Initializing OpenGL -----
Initializing OpenGL subsystem
Will create a fullscreen-window with resolution 1920x1080 (r_mode = -1)
SDL detected 1 displays: 
 0: 2560x1440 at (0, 0) to (2560, 1440)
Will use display 0 because mouse cursor is at (1946, 639).
Requested 8 color bits per chan, 8 alpha 24 depth, 8 stencil
Got 8 stencil bits, 24 depth bits, color bits: r8 g8 b8 a8
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: NVIDIA GeForce RTX 2060/PCIe/SSE2
OpenGL version: 4.6.0 NVIDIA 555.58.02


r_fullscreen 0
]vid_restart 
Shutting down sound hardware
Shutting down OpenGL subsystem
----- Initializing OpenGL -----
Initializing OpenGL subsystem
Will create a window with resolution 1920x1080 (r_mode = -1)
SDL detected 1 displays: 
 0: 2560x1440 at (0, 0) to (2560, 1440)
Will use display 0 because mouse cursor is at (1462, 1048).
Requested 8 color bits per chan, 8 alpha 24 depth, 8 stencil
Got 8 stencil bits, 24 depth bits, color bits: r8 g8 b8 a8

[j4reporting]

the same assertion fails each time

here is the bt
procedure 1:

This system qualifies for Ultra quality!
Shutting down sound hardware
in_grabKeyboard: Will *not* grab the keyboard if mouse is grabbed, so global keyboard-shortcuts (like Alt-Tab) will still work
----- Game Map Shutdown -----
'vid_restart partial' succeeded in changing resolution and/or fullscreen mode
dhewm3: /home/<user>/src/github/doom3/dhewm3/neo/sys/glimp.cpp:728: glimpParms_t GLimp_GetCurState(): Assertion `ret.width == glConfig.winWidth && ret.height == glConfig.winHeight' failed.


Looks like dhewm3 1.5.4pre crashed with signal SIGABRT (6) - sorry!
  140478365763343 (unknown symbol)
  140478366122308 __pthread_kill_implementation
  140478365763165 gsignal
  140478365665537 abort
  140478365665309 __assert_fail_base.cold
  140478365731190 __assert_fail
  6365685 neo/sys/glimp.cpp:728 GLimp_GetCurState()
  6365747 neo/sys/glimp.cpp:612 GLimp_SetScreenParms(glimpParms_t)
  4618797 neo/renderer/RenderSystem_init.cpp:1998 R_VidRestart_f(idCmdArgs const&)
  4948776 neo/framework/CmdSystem.cpp:476 idCmdSystemLocal::ExecuteTokenizedString(idCmdArgs const&)
  4948776 neo/framework/CmdSystem.cpp:679 idCmdSystemLocal::ExecuteCommandBuffer()
  5205252 neo/framework/EventLoop.cpp:184 idEventLoop::RunEventLoop(bool)
  4967703 neo/framework/Common.cpp:2440 idCommonLocal::Frame()
  4295852 neo/sys/linux/main.cpp:452 main
  140478365671559 __libc_start_call_main
  140478365671754 __libc_start_main_alias_2
  4297860 _start
  18446744073709551615 (unknown symbol)
Aborted (core dumped)

[DanielGibson]

Does that also happen in the current master branch? Because imgui-rebased as been merged

[j4reporting]

yes sorry, I used the master branch.

[DanielGibson]

Ok - can you tell me what imgui menu -> video options says about "Current Resolution" and "Display Size", both in windowed mode and fullscreen mode (if needed because using imgui menu crashes on apply, configure that through console and use a full vid_restart)

Oh right, and if that also doesn't work because the assertion triggers just by opening the video menu, comment out the line with the assertion (neo/sys/glimp.cpp:728)

[j4reporting]

seems to work fine w/o the assertion.

windowed mode:
current: 1920x1080
display: 2560x1440

fullscreen mode: SDL_VIDEODRIVER=x11
current 2560x1440 (is correct )
display: 1920x1080 <===

fullscreen mode: with SDL_VIDEDRIVER=wayland
current 1920x1080
display 2560x1440
and it's scaled to fullscreen

the same with vkquake or ironwail. with SDL_VIDEODRIVER=x11 fullscreen uses the real resolution 2560x1440
shown in options/video mode
and with SDL_VIDEODRIVER=wayland the compositor scales the program to full screen.
video mode remains at 1920x1080 and in case of quake the gui gets bigger because of the scaling.

[DanielGibson]

does it say anything about "Physical" (it does when detecting display scaling) in the menu, next to Current Resolution and Display Size?

[j4reporting]

no.

in fullscreen mode the desktop size always equals the configured game resolution. ( x11 driver )

update: probably can´t detect any scaling, because the desktop is not scaled ( 100 % )

[Yamagi]

If I understand the problem right this behavior is kind of expected: Under Wayland the fullscreen handling is compositor dependent. In my experience tho common compositors (kwin, mutter, wlroots) don't support implement switching initiated by clients. When a client requests fullscreen mode, the client is a) put in exclusive fullscreen mode when it's drawable size matches the current resolution of the given display or b) scaled up / down if it's drawable size is lower / higher than the resolution of the given display. Fractional scaling and scaling awareness of the client shouldn't matter in exclusive fullscreen, the common compositors communicate a scaled display mode, but an unscaled drawable size. That might break assumptions made by the client, though.

[DanielGibson]

Does it help if at the end of GLimp_SetScreenParms(), around here: https://github.com/dhewm/dhewm3/blob/master/neo/sys/glimp.cpp#L685, maybe after that glConfig.isFullscreen = (SDL_GetWindowFlags( window ) & SDL_WINDOW_FULLSCREEN) != 0; line, you add
GLimp_UpdateWindowSize(); ?

[j4reporting]

no change.

all what was needed was commenting out the assert at line 728

[DanielGibson]

no change.

ok, I'll have to debug this on wayland

all what was needed was commenting out the assert at line 728

that's no solution - if the values in glConfig aren't correct (consistent with the actual sizes), other code will behave wrong (for example mouse cursor speed, possibly even rendering itself)

[DanielGibson]

I pushed a fix for this to master.

Overall that case is still kinda broken (no crash anymore, but mousecursor behaves weird), and that's a bug in SDL or Wayland.

I think the main underlying issue is that Wayland does not support real fullscreen mode.
It does not allow applications to switch the resolution (or display refreshrate, by the way).

So all you get is fugly hacks: In the native Wayland case (SDL_VIDEODRIVER=wayland) the Window uses the given resolution (1920x1080 in your case) but the compositor scales it to be a borderless fullscreen window (at 2560x1440 in your case). So the window renders at the lower resolution and all the coordinates are at that resolution and it at least kinda works.

In the XWayland case however it apparently creates a borderless fullscreen window at the desktop resolution (2560x1440 in your case, not the one you requested!). For some reason however, one SDL function (SDL_GetWindowDisplayMode() - which is supposed to return the resolution for the currently used fullscreen mode!) returns the requested resolution (1920x1080), while another (SDL_GetWindowSize() returns the actual resolution (2560x1440).

Due to dhewm3 using the wrong size (at least consistently now..), the mouse input can behave weird in this specific case (XWayland + "real" fullscreen at lower resolution).

Extra unfortunate: think in the past I've seen SDL_GetWindowSize() not returning the correct resolution when in real fullscreen mode (on systems that, unlike Wayland, actually support that), so I don't really want to use SDL_GetWindowSize() for everything..

[j4reporting]

So the mouse cursor could behave strangely in the GUI /PDA ? But mouse movement in game should not be affected?

Have to reboot to fedora again to test. The scaling with native Wayland and use of real desktop resolution with Xwayland is consistent with other apps I tried so far.
And so far I wasn't able to find any regression besides the crash in dhewm.