Record the HDMI check on the same monitor
Keep the 0.2.4 documentation to what was measured
Restart as the verified way out, the cable and VRR described by what was observed, HDR advice that matches a restarted session, and the update path for tools before 0.2.2.
Document the 0.2.4 changes
Update source in the diagnostic report, the 4K fix where this project's Gamescope is selected, and why a switch into Game Mode could leave the notification workaround unapplied before 0.2.4.
Document Gamescope selection in 0.2.3
Document 0.2.1: the mode filter, and only what was measured about the exit crash
Before you start now says to choose 3840x2160 rather than 4096x2160, and distinguishes
a system running this project's Gamescope build, where the wider mode is no longer
offered, from one running the system's own.
The crash when leaving Game Mode no longer calls itself harmless, no longer names the
Vulkan library as unloaded, and no longer says nothing is lost. It records what was read
out of core files and says plainly that the cause and the frequency are not established,
that no dialog appears, and that the command for clearing old dumps was wrong.
Safe Graphics says which case needs a Game Mode restart instead. Updates and recovery
says the update is cancelled if one of this project's parts cannot be restored. How it
works describes all four Gamescope corrections and which two are upstream. The build
guide documents the build root helper.
Audit the whole manual against the code and the issue trackers
Every page was read against the code that ships today and against every open and
closed issue on the tracker, and each finding was checked by a second reader
whose job was to refute it.
The largest correction is that the manual did not know releases 0.1.9 and 0.2.0
exist. It still said the cause of the corrupted Game Mode menus was unknown and
offered the three workarounds as the remedy, and it said in three places that an
update cannot deliver Gamescope. It now describes the fault as fixed in 0.2.0,
names the cause, and gives the order a system on 0.1.8 or older has to follow.
Three pages sent the reader to release 0.1.7 to get the source. That tag carries
two of the three Gamescope patches, so anyone following those instructions built
an image without the menu fix. They now point at Releases in general, the same
form the README already uses, so they do not go stale again. Complete build also
links to the section that gets the repository, which it never did.
Troubleshooting is grouped into eight topics with an index at the top. Section
titles are unchanged, so links into them still resolve. _Sidebar.md is new, so
the pages are no longer listed alphabetically, and Home reads in the order a
person actually works, with How it works last.
Also corrected, each against the code it describes: the installer no longer
hides disks with mounted partitions, the base only build leaves out the
corrected Gamescope and cannot be sent it afterwards, tools older than 0.1.8
refuse any release naming a file they do not know, and returning to the SteamOS
Gamescope build is a deliberate rule rather than a fault.
Three commands this manual tells the reader to run were executed on a test
machine before it was written.
Correct the resolution claim: a lower resolution is worse, not clean
Measured at 1080p60 on the tested machine: the corruption also appears in the
main Steam interface with no game running, which never happened at 2560x1440.
The earlier claim came from a short look that did not include the menus.
Rewrite the menu corruption entry so it claims only what was measured
Three settings each avoid the symptom on their own, two of them with the performance overlay off, so the entry no longer treats the overlay as the defining one. It names the scaling setting as the interface does, states the black border it costs, scopes HDR to the tested DisplayPort connection, and says plainly that the failing component is unknown.
Name what the glitching menus entry actually looks like, and what removes it
The menu panel itself draws correctly; everything around and behind it is destroyed. The entry says so, offers the mouse as a way to recognise the fault, and adds the GPU accelerated web views setting, which removes the corruption completely and makes the menus very slow. It states that the fault depends on that path and that the faulty component is not located.
Offer the mouse as a check for the glitching menus, and name the upstream report
Moving the mouse clears the corruption while the pointer keeps moving. Everything that clears it keeps the compositor drawing, which points at a frame not being redrawn rather than at the display or the drivers, and it matches gamescope#1964 against unmodified Gamescope on NVIDIA.
Narrow two claims in the glitching menus entry
The swaps rule out this project's patched builds as the cause but do not clear every part of the session, and a Windows display setting is not proof of what the cable carries. The advice that reinstalling or changing drivers will not help is unchanged.
Say that a lower refresh rate does not fix the glitching menus, but a lower resolution does
Measured on the tested display: the same resolution at 60 Hz glitches exactly as at 165 Hz. Reading the machine while a menu glitched and again while it was correct found an identical mode, buffer, format and size with nothing in any log, so only the drawing differs. The page also warns that a mode Windows offers can be absent here.
Say plainly that reinstalling or changing drivers will not fix the glitching menus
Four comparisons, each changing one component and each rebooted so everything started in
its normal order, left the glitching unchanged: the overlay SteamOS packages in place of
this project's build, the Gamescope SteamOS packages in place of this project's build, an
older installer integration, and a newer NVIDIA driver.
A reader who hits this should not spend a day reinstalling, so the page now says so and
lists what was tried. The two settings that clear it stay at the top, where they are useful
first.
Name both Steam launchers, separate tested drivers, and document the glitching menus
The documented way to switch the Remote Play receiver off named the Game Mode launcher
alone, so it stopped working on the desktop once the desktop launcher was covered too.
It now names both and carries a command that writes both overrides. The encoder and
notification sections say which launchers they attach to, and why the desktop has to
have LIBVA_DRIVER_NAME removed while Game Mode never sets it.
The driver list explains that a version this project tested and a version NVIDIA merely
documents for your GPU are different claims, and that the list says so when nothing
offered has been tested here.
A new entry covers the Game Mode menus drawing with glitches while a game runs and the
performance overlay is off, with the two display settings that clear it. It states what
is measured and what is not: the same glitching appears with the overlay SteamOS
packages and on an older installer integration, the tested mode was DisplayPort at
2560x1440 and 165 Hz with HDR off, and that same mode is recorded as working with HDR
on.
Add the Desktop Mode findings, the 32-bit overlay symptom, and point at 0.1.7
Four entries from measurements on 2026-09-26: Remote Play receiving in Desktop
Mode, where Steam's client falls back to a decode path costing 153 ms per frame
and the answer is to switch hardware decoding off or receive in Game Mode;
outgoing capture pinned at 25 frames per second by how Steam drives the screencast
portal rather than by any limit of the portal; the Gamescope crash on leaving Game
Mode, which reproduces on Valve's own build and is reported upstream; and the
32-bit overlay dependency, whose symptom is a SIGSEGV that points nowhere near a
performance overlay.
Explain the receiver that cannot exit, and the two streaming symptoms that are not ours
A receiver left running after a streamed game ends keeps its last frame on
screen, so the machine looks hung while it works. The section says how to
recognise it, that the kernel truncates the process name, that SIGTERM cannot
work because the stuck thread is the one that would handle it, and that Installer
Update cannot deliver the fix because the driver is compiled.
Black bars and a flat washed out picture are host and client behaviour in Steam.
Both were measured, in both directions and on two SteamOS releases, and neither
can be fixed from this project, so the page says what they are and what to record
rather than offering a remedy that would not work.
The HDR section gains one measured observation: 2560x1440 at 165 Hz over
DisplayPort was stable on SteamOS 3.8.28, on one display, on one machine.
Document installer 0.1.2 notification fix and upgrade path
Document complete builds and Windows setup
Add installation manual and troubleshooting guides