ValveSoftware
[Question] Ability to autodetect and output native monitor resolution
Is there an option to autodetect the current monitors resolution and output the gamescope window at that resolution?
Essentially what I want is the behavior of how most games work when set to fullscreen. They will detect the native resolution of the screen and output at it. Most of the time I don't use any of the scaling features but I do appreciate the many other benefits that gamescope brings.
Normally manually setting the screens resolution is pretty quick and painless, however I often find myself switching between two screens that have different resolutions and it's a bit of a pain to have to edit the command line options every time I switch back and forth and for every game.
If a 'native output' option doesn't exist, could it be a feature on the horizon?
Oh, interesting. The first few times I tried, it defaulted to 720p. It works fine now that I try again though. I must've set something up wrong. Nevermind then, perfect.
Just tried this myself - using -f by itself uses the default 720p resolution, not the monitor's native resolution. Is annoying if you're trying to provide launch options for others to use, without assuming what their monitor resolution or aspect ratio might be.
same as @HelmicNewciv using the fullscreen flag doesn't work for me, it defaults to 720p, @Nano-Ocelot could you re-open this subject as it's apparently not resolved.
I need this feature as well, I cant use gamescope properly as I am switching between a 4k display ,and a widescreen gaming display depending on when I play.
So bascially I either have to always switch the gamescope command, or change the resolution in the game which is annoying. ( and sometimes does not even work )
I need this feature as well.
FYI: current gamescope master defaults g_nOutputHeight to 720 in the Wayland backend: here, which probably causes the low resolution by default.
g_nOutputHeight is later also set in the libdecor configure callback, but somehow this doesn't seem to propagate to the game, or at least doesn't seem to update to the monitor resolution.
I think I'll try to debug what's happening here a little more soon, maybe I can get behind what's happening here.
I looked into this a bit more today and implemented an experimental option to automatically adjust the nested internal resolution to the resolution of the output window/monitor. The implementation is available in my branch Ferdi265/gamescope#add-nested-auto-resize
The problem is that gamescope only sets the X11 server resolution once at startup, to whatever g_nNestedWidth/g_nNestedHeight is set to. g_nOutputWidth/g_nOutputHeight is updated later to the size of the Wayland window in the libdecor configure callback, but this isn't propagated to neither g_nNestedWidth/g_nNestedHeight nor the wlr_output resolution for the nested compositor. The initial setting of the resolution happens in wlserver.cpp:1657 in the constructor of gamescope_xwayland_server_t.
My experimental branch adds a --nested-auto-resize option that makes gamescope automatically adjust the internal resolution to the window/monitor resolution. It works quite okay from quick testing (with a dead-simple X11 test application), but I haven't tested it with games yet.
It works quite okay from quick testing, but I haven't tested it with many games yet.
Did a bit more testing and it doesn't work with Blue Prince for example. It might be that the resolution is updated too late and the game doesn't notice. In that case it might make sense to delay launching the game until the first real resolution is known.
My patch also completely ignores the XAtom-based mechanism that gamescope has for games to also change the resolution, so that might also be a point where this clashes.
Further testing and tinkering is needed, but this should be solvable.
EDIT: For now I can't seem to figure out how to make the WaylandBackend wait for the first real resolution before launching the game since the game window only appears when the game process has already been launched. If I have any new ideas I'll try them, but this will probably be the state that it's in for a while.