Steam Deck Controller Glyphs Wrong in Unity Input System - Layout Detection and Prompt Swap Fix

Problem: On Steam Deck (or when testing a Linux player build aimed at Deck), gameplay bindings from the Unity Input System feel correct—Jump and Interact fire as expected—but your UI prompts still show Xbox-style face buttons, wrong A/B positions, or mismatched stick icons. Players blame the game even though input is wired.

Root cause (typical): Prompt widgets are hard-coded to one sprite atlas (usually Xbox), while the Deck gamepad is often exposed through Linux as a standard HID gamepad with different physical labels than what players read on the hardware. Separately, your control scheme in the Input Actions asset may bind correctly but never drive a runtime prompt theme switch when the active device changes.

This article assumes you already use the Input System package and that actions work. If actions fail entirely on device, start with Unity New Input System Actions Not Working in Build Only - How to Fix and Unity Input System Not Working - New Input System Fix.

Quick fix checklist

Log the active InputDevice description on Deck (product, manufacturer, interface) once when a gamepad is connected.
Map that description to a prompt set (Deck, Nintendo-style, Xbox, DualSense) instead of assuming Gamepad.current always means Xbox art.
If you ship on Steam, evaluate Steam Input glyph APIs for official prompt textures when running under the Steam client—keep Input System for gameplay and use Steam for glyphs only if your integration supports it.
Retest a Linux player build on Deck desktop mode; the Windows Editor with a generic pad will not prove Deck prompt logic.

Step 1 - Confirm what Unity sees on Deck

Ship a Development Build for Linux or run on Deck in desktop mode with logging enabled.
When the player presses any bound button, log Gamepad.current?.deviceId, Gamepad.current?.description.product, and Gamepad.current?.description.manufacturer.
Compare against the same logs from an Xbox controller on PC.

Verification: You should see stable strings you can match with a small allowlist (exact or substring rules you document in code comments).

Common mistake: Testing prompt logic only in the Windows Editor with XInput—Deck Linux paths differ.

Step 2 - Drive prompts from active device, not from platform macros

Subscribe to device changes (InputSystem.onDeviceChange) or PlayerInput callbacks such as onControlsChanged, depending on your setup.
When the current gamepad changes, select a prompt theme. Deck-like layouts often need South/East button icons that match Nintendo mental models even when bindings use Xbox names internally. Keep one source of truth for which sprite maps to each action per theme.
Refresh all visible prompts when the theme changes mid-session (hot-plug).

Pro tip: Store themes as ScriptableObjects or addressable dictionaries keyed by an enum (PromptFamily) so localization and art passes do not fork your UI code.

Step 3 - Align Input Action control schemes with prompt families

Open your Input Actions asset.
Ensure binding groups (Keyboard, Gamepad, Deck) match what PlayerInput or your resolver enables.
If Deck shares the same bindings as generic Gamepad, that is fine—still use a separate prompt family when description rules identify Deck.

Common mistake: Duplicating every binding twice instead of one binding set plus two prompt atlases.

Step 4 - Steam Input (optional but strong on Deck)

When the game runs inside Steam, Steam Input can provide glyph handles that match what the player sees on hardware. This does not replace Unity Input System for most teams—it replaces guesswork for texture choice.

High-level integration shape:

Keep gameplay reads on Input System actions as today.
When drawing prompts, ask Steam for the glyph for the mapped action if the Steam API is available; fall back to your Deck or Xbox atlases offline.

If you are not ready for Steam Input, ship Deck-specific atlas fallbacks first—they solve most player-facing confusion.

Alternative fixes

Other input middleware with built-in glyph tables still needs Deck rows verified on device.
Touch prompts in desktop mode should not reuse gamepad sprites—detect pointer versus pad explicitly.

Prevention

Add one automated smoke scene that prints active device description and shows all face button prompts for the current theme.
Freeze prompt atlas naming (South, East, North, West) mapped to Input System button controls so art swaps do not break bindings.

FAQ

Should I use Xbox or Nintendo art for Deck?
Use what matches player expectations on the hardware they see. Many teams use a Deck or Switch-style face layout for prompts while keeping internal action names Xbox-oriented.

Why do bindings work but prompts fail?
Bindings read controls; prompts read your UI layer. They only stay in sync if you update both from the same device change event.