FSR filter restricts mouse to nested dimensions instead of scaling to output dimensions in Firestone

[DanielR-I]

Is there an existing issue for this?

• I have searched the existing issues

Are you using any gamescope patches or a forked version of gamescope?

• The issue occurs on upstream gamescope without any modifications

Current Behavior

The FSR filter when combined with output/nested scaling restricts the mouse to the nested dimensions instead of scaling to the output dimensions. Although it visually looks like the mouse is tracing well within the gamescope window, clicks/hovers need to be in the 720 location to work.

Steps To Reproduce

1. Launch Firestone (gameid 1013320) with the following launch options "DRI_PRIME=1 gamescope -r 60 -o 30 -h 720 -H 1360 -F fsr -- %command%"
2. typically a "popup" is presented with a button to "collect loot"... do not try click it, but try to mouse over it... the color of the button changes when hovered over... try find where the 720 position would be to see the color change
3. for some reason you can click the "gear" (upper right corner) where it is, but on the menu that follows you cannot click the button to save/exit; however, if you move the mouse to the approximate 720 location, you will see the buttons highlight as you mouse over where their 720 position would be within the 1360 display window

Note: Firestone supports Linux natively, but I cannot throttle it's FPS via launch options unless I force the use of Proton (typically experimental)

Hardware information

- Distro: Manjaro KDE Plasma 6.1.5
- CPU: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
- iGPU: AMD Radeon 780M (RADV GFX1103_R1)
- dGPU: AMD Radeon RX 7700S (RADV NAVI33)
- Driver Version: Mesa 24.2.4-arch1.0.1

Software information

- Desktop environment: KDE Plasma 6.1.5
- Session type: Wayland
- Gamescope version: 3.15.5
- Gamescope launch command(s):

Which gamescope backends have the issue you are reporting?

• Wayland (default for nested gamescope)
• DRM (default for embedded gamescope, i.e. gamescope-session)
• SDL
• OpenVR

Logging, screenshots, or anything else

Another scenario that highlights the mouse issue when nested/output scaling with fsr

1. Set the launch option so the scaling is 1:1
   "DRI_PRIME=1 gamescope -r 60 -o 30 -h 720 -H 720 -F fsr -- %command%"
2. Note that mouse overs/clicks work as expected @ 1:1
3. Maximize the gamescope window
4. Note that the mouse overs/clicks are no longer aligned as in the original scenario with scaling

Other steam launcher options that yielded the same issue:

1. change backend to sdl
   DRI_PRIME=1 gamescope -r 60 -o 30 -h 720 -H 1360 -F fsr --backend sdl -- %command%
2. set sdl driver to x11
   DRI_PRIME=1 SDL_VIDEODRIVER=x11 gamescope -r 60 -o 30 -h 720 -H 1360 -F fsr --backend sdl -- %command%

Other steam Launcher options that seem to "work around" the issue

1. Swap Filter to linear instead of fsr... highlights the issue is with fsr mouse scaling as linear scaling works as expected
   DRI_PRIME=1 gamescope -r 60 -o 30 -h 720 -H 1360 -F linear -- %command%
2. Add "--force-grab-cursor"... fixes the mouse scaling but locks the mouse to the window which is not desired to trap mouse for a windowed game
   DRI_PRIME=1 gamescope -r 60 -o 30 -h 720 -H 1360 -F fsr --force-grab-cursor -- %command%

Important observation

Eternium is another F2P game where I use gamescope to restrict the FPS, and it has no issues using the fsr filter with the same output/nested scaling (DRI_PRIME=1 gamescope -r 60 -o 30 -h 720 -H 1360 -F fsr -- %command%)... so the issue may be specific to Firestone and/or titles using the Unity game engine,

What's interesting is that back in gamescope 3.14.2 Eternium launched with an empty gamescope window if I used fsr whereas Firestone had no issues... and over time (game changes, gamescope changes, plasma changes) it's now Firestone that is having issues with fsr and Eternium does not.