Resolution stuck at in-game-resolution after closing Battlefield 1

[ms178]

Testing the new NTSync implementation today, I saw an unrelated issue with Battlefield 1. While my monitor's native resolution is WQHD at 165 Hz, I play games in FHD at 119,997 Hz. The desktop is set to WQHD and 119.997 Hz. After a gaming session, normally the screen has no problem with changing back to the mentioned resolution/refresh rate used there. But with the proton-tkg-winesync-git package which CachyOS provided for testing the NTSync implementation, the resolution is stuck at FHD after closing the game and the FSR-effect is also still visible.

I haven't encountered this issue yet with other Proton versions that I've used with that game, e.g. Proton 7.0-5, Proton-Cachyos or Proton-GE.

❯ inxi -GSC -xx
System:
  Host: klx99 Kernel: 6.1.5-3.2-cachyos-bore-lto arch: x86_64 bits: 64
    compiler: clang v: 16.0.0 Desktop: KDE Plasma v: 5.26.80 tk: Qt v: 5.15.8
    wm: kwin_x11 dm: SDDM Distro: CachyOS
CPU:
  Info: 18-core model: Intel Xeon E5-2696 v3 bits: 64 type: MT MCP
    arch: Haswell rev: 2 cache: L1: 1.1 MiB L2: 4.5 MiB L3: 45 MiB
  Speed (MHz): avg: 2312 high: 3790 min/max: 1200/2301 boost: enabled cores:
    1: 2301 2: 2301 3: 2301 4: 2301 5: 2301 6: 2301 7: 2301 8: 2301 9: 2301
    10: 2301 11: 2301 12: 2301 13: 1241 14: 2301 15: 2301 16: 2301 17: 2301
    18: 2301 19: 2301 20: 2301 21: 2301 22: 2301 23: 3790 24: 2301 25: 2301
    26: 2301 27: 2301 28: 2301 29: 2301 30: 2301 31: 2301 32: 2301 33: 2301
    34: 2301 35: 2301 36: 2301 bogomips: 165744
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: AMD Vega 10 XL/XT [Radeon RX 56/64] vendor: Micro-Star MSI
    driver: amdgpu v: kernel arch: GCN-5 pcie: speed: 8 GT/s lanes: 16 ports:
    active: DP-3 empty: DP-1,DP-2,HDMI-A-1 bus-ID: 05:00.0 chip-ID: 1002:687f
  Display: x11 server: X.Org v: 21.1.99 with: Xwayland v: 22.1.7
    compositor: kwin_x11 driver: X: loaded: amdgpu unloaded: modesetting
    alternate: fbdev,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 96
  Monitor-1: DP-3 mapped: DisplayPort-2 model: HP X27q res: 2560x1440
    dpi: 109 diag: 685mm (27")
  API: OpenGL v: 4.6 Mesa 23.1.0-devel (git-267dd1f4d5) renderer: AMD
    Radeon RX Vega (vega10 LLVM 16.0.0 DRM 3.49 6.1.5-3.2-cachyos-bore-lto)
    direct render: Yes

[Iglu47]

Thanks for the report. Unfortunately I don't have a game to test. This build with ntsync is based on wine-staging, not Proton_7.0 or Experimental_7.0, can you confirm there is no problem on proton-tkg based on wine-staging without ntsync or WINE_DISABLE_FAST_SYNC=1 ?

[ms178]

I could replicate the mentioned problem with the resolution with Total War:Troy. Will try and test with WINE_DISABLE_FAST_SYNC=1 next and update this post. Edit: The issue also persists when using WINE_DISABLE_FAST_SYNC=1.

[ms178]

Interestingly, I didn't get that problem with Company of Heroes 2 that uses D3D9 via DXVK (ga22d70e1) wheras Troy and Battlefield 1 use D3D12 via vkd3d-proton (g5e2c9880).

[Tk-Glitch]

Those winesync builds are based on upstream wine, for which we are currently disabling the fshack as its awaiting a rewrite. Without it, there will be a modeset. That's totally expected behavior and not a bug. Edit: by the way there's no fsr support in those builds since it depends on the fshack, so that part is placebo.

[ms178]

Certainly not placebo as the CachyOS packager also included the patches from proton-ge, where FSR is included. My reported problem is likely a bug in upstream wine though.

[Tk-Glitch]

You cannot add FSR patches if the fshack code isn't there. It's not there in wine upstream based builds since the fshack patchset simply isn't compatible with current wine trees. GE builds are using Valve's proton bleeding edge which is using wine 7.0 as base at this point in time. The 7.0 fshack patchset cannot be applied to 8.0 trees and needs a complete rewrite (which is pending for Valve's proton 8.0 and non-trivial). There is currently no workaround.

Again, there is no bug. Without the fshack there is no builtin FSR and games are free to modeset (setting your resolution and refresh rate). While some games might have some logic to restore your previous resolution and refresh rate on exit, it's not the case for most of them. The fshack was literally made to bypass this problem.

[ms178]

@Tk-Glitch Maybe I should have pointed out that I used a build from the CachyOS maintainer who did some porting work himself and added some additional patches. As I have Proton versions with and without FSR, I can visually compare the results. If you don't trust my eyes and my countless hours testing games during the last years, fine - this is a side discussion anyways. The main problem is that with that build, my desktop resolution was not honored when exciting from Battlefield 1 and Total War Troy whereas it was fine when exciting Company of Heroes 2. That means that there clearly is a bug somewhere (or I wouldn't have posted this as an issue in the first place) as it wasn't the result which I expected.

It might not be TKG's bug, though. So here is an apology from me as I came to the conclusion that this bug was posted with the wrong project entirely. Therefore I am closing this for now.

[ms178]

To illustrate it a bit better, this is what I got in that situation:

This is what it is supposed to be:

[Tk-Glitch]

Those shots are demonstrating exactly what I said above: no FSR, and a modeset happened (and your wallpaper was scaled accordingly).

The fact ptr1337 or whoever else has made some porting work or added patches by himself doesn't matter here. Rewriting the fshack from scratch against wine 8.0 isn't something you do in a couple hours between two beers. It's something that's non-trivial for a CW or Valve wine dev. I explained why it's happening and why it's not a bug. If my explanations were unclear I'm sorry, I tried my best.

[ptr1337]

Those shots are demonstrating exactly what I said above: no FSR, and a modeset happened (and your wallpaper was scaled accordingly).

The fact ptr1337 or whoever else has made some porting work or added patches by himself doesn't matter here. Rewriting the fshack from scratch against wine 8.0 isn't something you do in a couple hours between two beers. It's something that's non-trivial for a CW or Valve wine dev. I explained why it's happening and why it's not a bug. If my explanations were unclear I'm sorry, I tried my best.

Actually he mixes some stuff up. The "proton-tkg-winesync-git" is simply based on the proton upstream option of wine-tkg-git, not more. I did not any other patches, its the default configuration.

proton-cachyos is simply proton-experimental/wine-bleeding edge with the FSR patches applied. Not more.

[Tk-Glitch]

So, for the last time I'll try to be clear with @ms178 thanks to your clarification @ptr1337 .

In the case of the "proton-tkg-winesync-git" build, it's based on wine upstream and doesn't come with the fshack (so it doesn't have builtin FSR). As a result, the behavior you reported is expected and normal (as in not a bug).

In the case of the "proton-cachyos" build, it's based on Valve's proton experimental bleeding edge, which comes with the fshack (and @ptr1337 applied the FSR patches to it). That build shouldn't have the same behavior as what your reported since the fshack will prevent modesets (your desktop resolution will never change, and the games will get scaled to it by the fshack). If your issue happened with the proton-cachyos build, that's not normal and can be considered as a bug.

[ms178]

Thanks for the clarification to you both. This wasn't seen with proton-cachyos but with proton-tkg-winesync-git. Even if the shown behavior is expected, as a user and tester, I clearly wouldn't have expected that to be normal behavior and therefore treated this anomaly as a bug, hence you got my report here.