scripts: add MSI Claw 8 AI+ LCD profile

[JohnnySun]

Summary

Add a known-display profile for the MSI Claw 8 AI+ internal LCD panel:

• EDID vendor/model/product: CSW / PN8007QB1-2 / 0x0801
• Native resolution: 1920x1200
• Dynamic refresh range: 48-120Hz
• HDR: unsupported

The modegen timings are taken from the panel mode observed on hardware:

• Horizontal: front porch 48, sync 32, back porch 80
• Vertical: front porch 54, sync 6, back porch 4

Hardware Validation

Tested on an MSI Claw 8 AI+ A2VM running SteamOS with gamescope 3.16.23.2 by installing the Lua profile under /etc/gamescope/scripts.

Before this profile, gamescope treated the panel as unknown and only exposed the EDID's 60Hz and 120Hz modes. After adding the profile and restarting the gamescope session, gamescopectl reported:

Display Make: China Star Optoelectronics Technology Co., Ltd
Display Model: PN8007QB1-2
Display Flags: 0x5
ValidRefreshRates: 48, 49, 50, ..., 120

The gamescope log also reported:

drm: Got known display: msi_claw_8_ai_plus_lcd (MSI Claw 8 AI+ LCD)
drm: selecting mode 1920x1200@120Hz

Notes

This change only adds the gamescope display profile. A separate Steam Client beta UI regression was observed while testing this panel, where the beta Display settings page assumes DisplayManager.GetState() always returns game_resolution_override_default. That issue appears to be in the Steam Client UI/native DisplayManager path rather than in this gamescope display profile.

[matte-schwartz]

unfortunately this config file does not work. it seems to lock to ~half of the fixed FPS limit/refresh rate. I'll debug it when I have some time, might be something in the kernel driver or Mesa.

[JohnnySun]

@matte-schwartz I reproduced this on my Claw 8 AI+ with gamescope 3.16.23.2 on 6.16.12-valve24.1, and I agree this needs more work before merging.

A few things I confirmed:

• The profile is matching the panel correctly. gamescopectl reports PN8007QB1-2 and ValidRefreshRates: 48..120.
• With VRR disabled, the current calc_max_clock() profile does set the requested DRM modes, but some of them present at half rate:
  • 100Hz: DRM 1920x1200@100.00, clock 262912, app stats ~100 FPS
  • 96Hz: DRM 1920x1200@96.00, clock 252396, app stats ~48 FPS
  • 90Hz: DRM 1920x1200@90.00, clock 236621, app stats ~45 FPS
• I reproduced the same 100Hz-ok / 96Hz-and-90Hz-half-rate shape on a second Proton title, so this is not just one game.
• gamescope logs show it selecting the requested modes, and Gamescope WSI receives the expected cycles, e.g. 96Hz -> 10.42ms, 90Hz -> 11.11ms. So the mode switch and WSI cycle are not simply being reported as half rate.

I also tested a temporary fixed-pixel-clock / VFP modegen variant, similar to the ROG Ally / Deck OLED style:

• 100Hz: clock 315500, adjusted vtotal 1517, app stats ~100 FPS
• 90Hz refresh-only: clock 315500, adjusted vtotal 1685, app stats ~90 FPS
• 96Hz still presented at ~48 FPS
• combined limit+refresh at 90Hz still presented at ~45 FPS

So my current read is:

1. The PR as-is is not ready; the calc_max_clock() modegen is at least part of the problem, and fixed-clock/VFP looks like a better baseline for this panel.
2. The exact fixed FPS limit + refresh half-rate issue you saw is not fully solved by the Lua modegen change. It still appears in the combined limiter path even with fixed-clock timings, so there seems to be a second present-pacing issue in the fixed-mode path, outside of just display matching/rate exposure.

I will rework the profile toward fixed-clock/VFP and keep the combined limiter issue called out instead of presenting that as a complete fix.

[JohnnySun]

Correction after retesting: my fixed-clock/VFP 90Hz result above was not stable/reproducible. After rerunning with both Aokana and Tiny Snow, fixed-clock 90Hz still presents at ~45 FPS even with the FPS limiter disabled / refresh-only mode.

So the conclusion should be narrowed: fixed-clock/VFP may still be a better direction than the current calc_max_clock() modegen, but it does not by itself fix the half-rate behavior. The remaining issue looks more broadly tied to the fixed generated 90/96Hz mode present-pacing path, rather than the combined limiter alone.