SteamOS beta Display settings crashes when DisplayManager.GetState omits game_resolution_override_default

[JohnnySun]

Your system information

• Steam client version: beta build 1782517397
• SteamOS version: SteamOS 3.8.11, build 20260620.1
• Steam Runtime Version: Steam Runtime 3c / sniper, as launched by steamwebhelper
• Distribution: SteamOS Holo
• Opted into Steam client beta?: Yes, steamdeck_publicbeta
• GPU: Intel Lunar Lake iGPU, Mesa 25.3.0
• Hardware: MSI Claw 8 AI+ A2VM
• Display: internal eDP-1, EDID vendor/model/product CSW / PN8007QB1-2 / 0x0801, native 1920x1200

Please describe your issue in as much detail as possible:

On Steam beta build 1782517397, opening the SteamOS Big Picture Settings > Display page crashes the page with:

TypeError: Cannot read properties of undefined (reading 'width')

The visible error page reports:

Error Reference: Shared SteamUI_10780134_89606695adcf6ee7

Using the Steam WebHelper CDP console, SteamClient.System.DisplayManager.GetState() succeeds, but its protobuf reply omits game_resolution_override_default:

field 4 game_resolution_override_native = 1920x1200
field 5 game_resolution_override_default = <missing>

The beta Steam UI bundle then reads the missing field without a guard in the Display settings component:

TypeError: Cannot read properties of undefined (reading 'width')
    at j (https://steamloopback.host/chunk~2dcc5aaf7.js?...:1:8081620)

From the minified bundle, the crashing j() function reads l.data.width, where l is the selector for game_resolution_override_default.

The expected default value on this device is 1920x1200. Steam's native systemdisplaymanager.txt log shows the native path can compute it:

GetGameResolutionOverride: override: 'Default'
Using maximum game resolution: screen resolution: 1920x1200

Steam stable build 1782533657 on the same device also omits game_resolution_override_default from DisplayManager.GetState(), but the stable Display settings UI does not unconditionally read the missing field and renders successfully. The regression appears to be that the beta UI now assumes game_resolution_override_default is always present, while the native DisplayManager reply can still omit it.

While testing, I also added a gamescope known-display profile for this MSI Claw 8 AI+ panel. That fixes gamescope's panel identification and refresh-rate list, and is being proposed separately in ValveSoftware/gamescope#2236. It does not fix this Steam beta UI crash because the beta crash is caused by the missing DisplayManager.GetState() field described above.

Steps for reproducing this issue:

1. Use a SteamOS gamescope session on a non-Deck handheld where DisplayManager.GetState() does not include game_resolution_override_default.
2. Opt into Steam beta build 1782517397.
3. Restart Steam.
4. Open Big Picture Settings > Display.
5. Observe the Display page error:

TypeError: Cannot read properties of undefined (reading 'width')

Expected result

The Display settings page should render even when game_resolution_override_default is absent. Either:

• DisplayManager.GetState() should populate game_resolution_override_default with the screen-resolution default when gamescope_game_resolution_global is Default, or
• the Display settings UI should fall back to the current/native display resolution when this field is absent.

[JohnnySun]

Additional root-cause data from the affected MSI Claw 8 AI+ SteamOS device:

Steam beta build 1782517397 is internally consistent; this does not look like a corrupt update. The beta SteamUI bundle defines CMsgSystemDisplayManagerState.game_resolution_override_native as field 4 and game_resolution_override_default as field 5.

The live SteamClient.System.DisplayManager.GetState() reply from SharedJSContext decodes as:

top-level fields present: 1, 2, 3, 4
field 4 game_resolution_override_native.width = 1920
field 4 game_resolution_override_native.height = 1200
field 5 game_resolution_override_default = missing

The SteamUI beta Display settings component calls the selector for game_resolution_override_default and immediately dereferences data.width/data.height. The same default-resolution selector is also used from the app properties resolution override UI path. Stable does not make this unguarded read, so stable can render the page even though the native state on this third-party SteamOS device also lacks field 5.

The important detail is that the native default policy itself can resolve the value. The beta systemdisplaymanager.txt log contains:

GetGameResolutionOverride: override: 'Default'
Using maximum game resolution: screen resolution: 1920x1200

So the failure appears to be between the native game-resolution override policy and CMsgSystemDisplayManagerState serialization: the default value exists as a computed policy result, but is not included as game_resolution_override_default in GetState().

I also checked the gamescope side. The current gamescope_control v6 active_display_info event only sends:

connector_name
display_make
display_model
display_flags
valid_refresh_rates

The known-display Lua profile can fix panel identification and valid refresh rates, and it does make the device report native/current mode correctly, but there is no existing gamescope-control field or Lua profile key for Steam's default game-resolution policy. On this device, native/current mode is already present:

DisplayManager current mode: 1920x1200@120
game_resolution_override_native: 1920x1200
game_resolution_override_default: missing

Expected Steam-side fix candidates:

1. Populate game_resolution_override_default in GetState() when the default policy resolves to the current screen/native resolution.
2. Add a UI fallback so Display settings and app properties use game_resolution_override_native or the current display mode when field 5 is absent.

This seems specific to the new beta native/UI contract on third-party SteamOS/gamescope devices, not a broken panel mode or corrupted Steam package.

[SproedKartoffelChip]

ROCKNIX, Odin 3 (sm8750) on native aarch64 client experiencing the same issue.

[lostgoat]

The latest beta update should have a fix for this issue.

[SproedKartoffelChip]

Looks to be fixed post-update over here.