(SteamOS 3.6/3.7) "Revert" button after choosing new system-wide resolution in gamescope-session's GamepadUI stops working after 20895280

[matte-schwartz]

commit 2089528079d2c1e439e5b639d00e24c2127ba2bf
Author: Joshua Ashton <[email protected]>
Date:   Thu Mar 28 03:21:39 2024 +0000

    all: Use mHz everywhere for refresh rate stuff

 src/drm.cpp             | 46 +++++++++++++++++++++++++++++++++-------------
 src/headless.cpp        |  3 ++-
 src/main.cpp            |  5 +++--
 src/main.hpp            |  6 +++---
 src/refresh_rate.h      | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 src/sdlwindow.cpp       |  5 +++--
 src/steamcompmgr.cpp    | 23 +++++++++++++----------
 src/vblankmanager.cpp   |  7 ++++---
 src/vblankmanager.hpp   |  2 +-
 src/vr_session.cpp      |  3 ++-
 src/wayland_backend.cpp | 12 ++++++------
 src/wlserver.cpp        | 19 +++++++++++--------
 12 files changed, 128 insertions(+), 50 deletions(-)
 create mode 100644 src/refresh_rate.h

this commit breaks the "Revert" button in the Steam Deck's GamepadUI. After this point, hitting "Revert" after changing a screen's refresh rate/resolution does nothing rather than reverting to your previous good resolution. Tested on both Steam Deck OLED and on my 7900XTX, and this issue happens on both.

[matte-schwartz]

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: SAM
    Model: 29656
    Serial Number: 810635603 (0x30515153)
    Made in: week 15 of 2024
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 140 cm x 40 cm
    Gamma: 2.20
    DPMS levels: Off
    RGB color display
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6806, 0.3046
    Green: 0.2724, 0.6660
    Blue : 0.1552, 0.0556
    White: 0.3134, 0.3291
  Established Timings I & II:
    DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
    DMT 0x06:   640x480    75.000000 Hz   4:3     37.500 kHz     31.500000 MHz
    DMT 0x09:   800x600    60.316541 Hz   4:3     37.879 kHz     40.000000 MHz
    DMT 0x0a:   800x600    72.187572 Hz   4:3     48.077 kHz     50.000000 MHz
    DMT 0x0b:   800x600    75.000000 Hz   4:3     46.875 kHz     49.500000 MHz
    DMT 0x10:  1024x768    60.003840 Hz   4:3     48.363 kHz     65.000000 MHz
    DMT 0x11:  1024x768    70.069359 Hz   4:3     56.476 kHz     75.000000 MHz
    DMT 0x12:  1024x768    75.028582 Hz   4:3     60.023 kHz     78.750000 MHz
    DMT 0x24:  1280x1024   75.024675 Hz   5:4     79.976 kHz    135.000000 MHz
  Standard Timings:
    DMT 0x15:  1152x864    75.000000 Hz   4:3     67.500 kHz    108.000000 MHz
    DMT 0x55:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    DMT 0x1c:  1280x800    59.810326 Hz  16:10    49.702 kHz     83.500000 MHz
    DMT 0x23:  1280x1024   60.019740 Hz   5:4     63.981 kHz    108.000000 MHz
    DMT 0x2f:  1440x900    59.887445 Hz  16:10    55.935 kHz    106.500000 MHz
    DMT 0x53:  1600x900    60.000000 Hz  16:9     60.000 kHz    108.000000 MHz (RB)
    DMT 0x3a:  1680x1050   59.954250 Hz  16:10    65.290 kHz    146.250000 MHz
    DMT 0x52:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
  Detailed Timing Descriptors:
    DTD 1:  2560x2160   59.978424 Hz  32:27   133.272 kHz    362.500000 MHz (1400 mm x 400 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync  10 Vback   49 Vpol N
    Display Range Limits:
      Monitor ranges (GTF): 60-75 Hz V, 30-134 kHz H, max dotclock 370 MHz
    Display Product Name: 'Odyssey G95NC'
    Display Product Serial Number: 'HNTX400694'
  Extension blocks: 1
Checksum: 0xb4

I have narrowed down the issue significantly. The revert button stops working if you go from a refresh rate like 2560x2160 59.978424 Hz -> an even number like 1920x1080 60.000000 Hz and then proceed to try and use the pop-up to set it back to the original 2560x2160 59.978424 Hz. The same applies for the other display timings and their relative counterparts. If I try to go from 1600x900 60.000000 Hz -> 1920x1080 60.000000 Hz though, then the revert button works as expected. maybe there's some sort of rounding error in the revert logic similar to what we saw with the BOE OLED Deck?

[matte-schwartz]

I spent the day looking into this and I am not sure this is a real gamescope issue, but rather something in the Steam client backend logic for OnOutputMode, RematchCurrentMode, or ApplyCompatibilityModesIfNecessary that causes "Revert" to fail with modelines that do not end in .000000 for external displays, along with a plethora of new issues reported elsewhere.

As part of my cursed testing, I rolled back to SteamOS 20240327.1000 which has gamescope 3.14.2-2 with the old refresh rate logic and stared at ~/.steam/steam/logs/systemdisplaymanager.txt while going through several of the Display-related regressions in the SteamOS repo. Basically all of them boil down to the fact that modes that would previously be reported as RematchCurrentMode: trying to find modeid that matches: [email protected] with pre-3.14.2 gamescope now get reported as RematchCurrentMode: trying to find modeid that matches: [email protected] with post-3.14.3 gamescope.

While the new logic is actually closer to what my EDID reports in the DTD timings for the corresponding mode, any modelines that now get reported with different non .000000 values seem to have the following issues within the Steam UI:

• mode switches instigated by the "Revert" button stop functioning, as reported in both this issue and Reverting from a video resolution change in gaming mode settings does not do anything. SteamOS#1715
• the resolution menu turns blank while these modes are selected, as reported here: Resolution drop-down is always blank SteamOS#1718

Additionally, one unreported issue:

• the "Safe Mode" that should be triggering ApplyCompatibilityModesIfNecessary stops functioning with [email protected] without any clear debugging logs as to why

If you start getting creative in

gamescope/src/Backends/DRMBackend.cpp

Line 103 in 7dd1bcd

int32_t nRefresh = (mode->clock * 1'000'000ll / mode->htotal + mode->vtotal / 2) / mode->vtotal;

and

gamescope/src/Backends/DRMBackend.cpp

Line 869 in 7dd1bcd

static const drmModeModeInfo *find_mode( const drmModeConnector *connector, int hdisplay, int vdisplay, uint32_t vrefresh )

you can technically restore the old behavior for every issue above by locking it back to refresh rates that end in .000000 only, but Misyl's comments in

gamescope/src/refresh_rate.h

Line 12 in 7dd1bcd

constexpr int32_t ConvertmHzToHz( int32_t nRefreshmHz )

make me think that gamescope technically should have no problem with rounding these refresh rates like this.

@kisak-valve ultimately, this has turned into something that involves a large amount of issues for what appears to be a single core problem and I'm not sure how you'd like to handle organizing this. my best guess is its going to be something in the Steam Client code, but maybe I'm overlooking something obvious here in gamescope.