NX2navi on Steam Deck: Setup and Compatibility

01 /

Can NX2navi run on Steam Deck?

The project includes native Linux work and a Deck-specific configuration profile. Those are meaningful development signals, but they answer different questions from whether a particular Steam Deck can build the game, reach gameplay, preserve input and perform consistently across scenes. The referenced release explicitly limits the developer's Linux testing.

This NX2navi Steam Deck guide therefore offers a preparation and verification workflow rather than an invented successful installation walkthrough. There is no frame-rate table from this website because we have not run the game on the device. A future result should identify the actual handheld model, SteamOS version, port version, driver and settings.

02 /

Record the SteamOS environment before installation

Start in a context where you can inspect files, terminal output and logs, normally Desktop Mode for preparation. Record the SteamOS release and kernel, available space on the intended output drive, and the official package you are using. Do not confuse free space on an SD card with free space on a different filesystem selected by a build script.

The native Linux requirements include compiler/linker tools and system libraries as well as Vulkan features. A Windows Setup EXE is not the native Linux installer. Running it through a compatibility layer would be a separate experiment whose result cannot be silently described as native SteamOS support.

In Desktop Mode, locate the AppImage obtained from the official release and inspect its executable permission in the file manager. The Linux guide shows the matching chmod and terminal-launch syntax. Keep the first terminal error and classify it as permission/architecture, toolchain, Vulkan or game-input related. These are preparation and observation steps, not a Steam Deck installation we have verified.

Use the Linux guide for the actual Build Kit example and dependency distinction. Keep your own compatible game input separate from output. If the build fails before a playable executable exists, changing a frame cap or controller layout cannot repair a missing compiler.

• Record LCD/OLED model and system software without assuming that one model proves the other.
• Check the output drive, RAM pressure and power/suspend conditions for a lengthy local build.
• Keep the full first error and stage name so a later report can distinguish packaging from runtime.

03 /

Understand the built-in Steam Deck device profile

The INI reference accepts device_profile = auto, desktop or deck. The selected profile is read at startup and provides defaults for keys that the user has not explicitly set. Existing explicit values can therefore explain why selecting a profile does not appear to change a setting.

The documented Deck defaults include an FPS cap of 40, four cores and FIFO presentation. These are starting choices, not measured recommendations or a promise that the device holds that rate. A frame cap limits work when the machine can reach it; it does not create the performance required to do so.

Be particularly careful with the profile's generic display fields. The same configuration reference explains that output_res and render_scale do not control the OoT image. Use game_aspect and game_res for the game-specific aspect and internal target height. The presence of a 1280×800 generic output value does not prove native 800p rendering for this game.

# Select the documented profile, then restart.
device_profile = deck
# Confirm game-specific display options in the matching reference.
# game_aspect / game_res control the OoT image.

04 /

Separate SteamOS packaging obstacles from handheld compatibility

Issue #421 reports SteamOS 3.9.5 with an RTX 5070 and missing build tools or headers. That is a desktop configuration running SteamOS, not a Steam Deck hardware test. It demonstrates a dependency problem in its described workflow, without measuring handheld graphics performance.

Likewise, Issue #430 is an Arch/RTX 4090 desktop account that explicitly excludes testing the Deck profile, AppImage and non-NVIDIA hardware. Do not transfer its FPS results to a handheld AMD APU.

SteamOS system management differs from a general desktop distribution. Disabling filesystem protection and installing a long package list should not be the default response to an AppImage error. Identify the missing dependency, compare the current official packaging instructions and understand any system change before applying it. A package-format promise is less useful than the actual failing command.

05 /

Check display and controls after a successful native launch

Once a completed game starts, confirm picture shape before raising graphics workload. A 16:10 handheld panel and the game's selected aspect are separate concepts. Compare a documented aspect option with the actual viewport and restart for the game-specific settings that require it. Do not copy Windows DLSS or FidelityFX DLL instructions onto the Deck's native Linux path.

Open the settings menu using F1 or Esc with a keyboard, or the documented Minus+Plus controller combination. The controls reference uses SDL input and distinguishes button layout from on-screen prompt artwork. Selecting SteamDeck prompts is not proof that the needed prompt assets exist or that the physical input mapping changed.

For an unresponsive controller, check window focus, the last controller providing input and whether input was disabled before attempting broad remaps. Test a simple menu action and one gameplay action separately. The controls guide explains layout, prompts and binding recovery in detail.

06 /

Evaluate a NX2navi Steam Deck setup honestly

Choose a repeatable save and route, record resolution and graphics features, then observe actual rendered frames and frame pacing. Turn frame generation off for a baseline where available: a generated display frame is not another simulated game frame. F10 and the in-game performance panel can help collect the software's own observations.

Separate a first visit to a scene from a repeated route. Asset preparation, thermal state, background work and memory pressure can change a result. A screenshot showing 40 FPS in one position does not establish sustained 40 FPS through towns, transitions and demanding scenes.

A useful report also checks save/load, suspend/resume only if actually attempted, input after reconnecting, audio and a longer session. Mark untested features as untested. Do not supply guessed battery life or a best-TDP number without measurement.

1. Establish one stable baseline

   Keep the working configuration and copy the INI before experimenting. Record the profile and explicit overrides.

2. Change one variable

   Compare the same route after a documented resolution or cap change. Keep power and background workload comparable.

3. Report the complete context

   Include device model, SteamOS, kernel, port/game versions, driver, settings and the exact symptom; do not upload game data.

COMMON QUESTIONS

Frequently asked questions