Change handheld hotkeys and Pokémon game buttons

Choose the scope before changing a shortcut

If Hotkeys is absent, KNULLI says the selected system does not allow that customization. Do not force a RetroArch procedure onto a standalone emulator.

Check old customizations and conflicts

The KNULLI custom-hotkey guide says to remove old hotkey overrides or manual customizations before using its GUI workflow. Preserve a backup and record the previous choices before removing a relevant customization.

Its shortcuts combine the held Function button with another button. Some actions belong to the operating system and cannot be disabled or modified there. Assigning a second action to an operating-system shortcut can produce a double binding.

Test on disposable progress

1. Record KNULLI version, selected emulator and the one shortcut you want to change.
2. Choose game scope for an initial investigation and record the old binding.
3. Apply the GUI change, then launch and test the intended shortcut in a low-stakes scene.
4. Test the ordinary game controls separately so movement, confirm/cancel and shoulder inputs still work.
5. Quit normally and relaunch to check persistence. Verify Continue independently if a state action was involved.

Pick actions you can distinguish

Choose save-state and load-state inputs you can identify deliberately. Before using either on established progress, check the current state slot and retain an in-game backup. Do not repeatedly press a shortcut while diagnosing a delayed response.

For ordinary Pokémon saving, use the game's Save command. For lid actions on the SP, read the lid-close guide; a power or shell action is not the same setting as an emulator shortcut.

Separate inherited settings from a shortcut conflict

Record both the game's setting and the system setting before troubleshooting. KNULLI's Auto value inherits from a broader layer, while an explicit per-game choice can produce a different result. A persistent but unexpected action and a choice lost at launch are different observations.

• Changed only inside the running emulator: investigate generated configuration.
• One game differs from others: inspect its scope and existing customizations.
• One press performs two actions: check the operating-system shortcut conflict described above.

Use the configuration-layer checklist for the relaunch comparison and source limitations. Avoid assigning more buttons until you can reproduce the original symptom.

If a change disappears or performs two actions

Check that the emulator is RetroArch-driven, the customization scope matches the game and older overrides are accounted for. For two actions, investigate the operating-system binding before assigning more buttons. Change one setting at a time and keep the old configuration available.

Brick setup · SP setup · Plus setup. Documentation checked 6 Oct 2026.

Change Pokémon buttons without changing emulator hotkeys

If pressing a face button should mean a different Pokémon button, use a control remap. If holding Function should trigger an emulator action, use the Hotkeys menu above. First describe the action you want in plain words: “this button cancels a menu” and “this combination loads a state” are different requests.

The KNULLI RetroArch controls guide documents this path: during play, Function + B → Controls → Manage Remap Files. Inspect Active Remap File; leave common.rmp alone. For one title, choose Save Game Remap File, then return to Controls → Port 1 Controls. The left column is the device input; the right is the emulated input. Changes persist in the active remap.

Work on a harmless menu first. Identify what each original button does, then change the one mapping you actually need. Return to the same menu and check confirm, cancel and movement individually. If the intended action works but another familiar action is missing, inspect your assignments before changing a second configuration layer.

Why a saved remap can seem to disappear

KNULLI documents remap precedence as game over content directory over core over default. A directory remap remains specific to its core. A more specific active file can therefore hide the broader file you edited.

For a one-game experiment, keep the original mapping in your notes and choose game scope. If you later want to share the arrangement, first prove what the narrow experiment changed. Applying a core-wide remap immediately makes it harder to know which other games you affected.

The displayed active file is useful evidence. Write down its name before and after relaunch. “I saved a remap” leaves the important question open: was that the file used for this entry?

Worked example: a GBA preference works everywhere except one hack

1. Open an ordinary menu in a working title. Record the physical button and its visible result, plus the active remap name.
2. Repeat that observation in the exceptional title. Keep Function released while checking ordinary game buttons.
3. Inspect the exceptional title's active file. A game-specific file is a concrete lead; do not assume a broken global configuration.
4. If that exception is intentional, adjust its mapping. If it is unwanted, preserve it before using the documented Remove Game Remap File option. Verify the named file and scope before removal.
5. Relaunch the exceptional title and repeat the original confirm/cancel check. Then confirm a previously working title still behaves as intended.

A useful resolution names the action that changed and the file responsible. If nothing changes, keep the observed file names and reconsider the selected core or game entry. Repatching the game would introduce another variable without explaining the input configuration.

Use the setting-owner table for display preferences or emulator selection. For Drastic and Advanced-Drastic, use the DS emulator comparison instead of assuming this RetroArch procedure applies.

Button and shortcut questions

RetroArch controls documentation checked 7 Oct 2026. The worked case is an editorial diagnostic example. No preferred physical button arrangement or completed hardware test is claimed.

Which launch path are you using?

The EmuDeck wiki distinguishes EmuDeck - Controller Hotkeys for Steam game shortcuts from EmuDeck - Frontend Controller Hotkeys for frontend or emulator launches. Check the active Steam Input layout rather than assuming two launch methods share the same state.

Steam ROM Manager also distinguishes standalone Nintendo Game Boy Advance - mGBA from its RetroArch mGBA parser. If you selected the core, use that core's documentation rather than applying this standalone table.

Useful documented shortcuts

These combinations assume the documented profile. Personal layouts can differ. State actions are separate from choosing Save inside Pokémon.

Fast-forward does nothing?

1. Record emulator version, exact game build and whether you launched a Steam shortcut or a frontend.
2. Inspect the active Steam Input profile. For the documented frontend profile, hold Start for a few seconds to enter its hotkey action set.
3. Try in a low-stakes scene, then compare normal movement and fast-forward in that same scene.
4. Check ordinary game buttons separately. Stop if an action you need was replaced by a customization.

If the shortcut registers but acceleration is small, that differs from an input that never reaches the emulator. Record those observations without inferring a universal multiplier or a result for every Pokémon hack.

Protect progress around state shortcuts

Make an in-game save and retain a backup before experimenting with load-state controls. Avoid repeatedly pressing load while diagnosing a delayed response. Check team and location after any restore before saving over established progress.

For separate playthroughs, use mGBA player saves. For local trading, use the multiplayer guide. Neither workflow is established merely by a working hotkey.

Keep experiment controls separate from your playthrough

Before customizing several actions, record the profile and verify a single shortcut in a harmless scene. Then check ordinary movement, confirm, cancel and shoulders. If you use both direct Steam and frontend launch paths, repeat that check in each rather than assuming the second path uses the same action set.

For cheat-menu access, follow the standalone mGBA cheat guide. A menu opening correctly is an input result; it does not validate a cheat code. Preserve the original cartridge save and avoid combining new codes, remaps and a game update in the same experiment.

Select the Steam Input profile for the actual shortcut

1. Open Game Mode and select the relevant entry. Choose the Pokémon shortcut for a direct launch, or the frontend entry if you normally open the game through ES-DE. Keep a note of the current layout name.
2. Open the controller icon. EmuDeck documents selecting the layout name at the top to bring up the profile choices.
3. Match the launch path. Its documented direct-game template is EmuDeck - Controller Hotkeys; its frontend template is EmuDeck - Frontend Controller Hotkeys.
4. Check the action set. The frontend template includes a separate layer for standalone mGBA and related emulators. Hold Start as described by EmuDeck to switch to it.
5. Test, then return to normal play. Verify both the shortcut and ordinary controls in the game. Do not assume a profile's name proves it is behaving correctly.

EmuDeck's Steam Input profile guide explains the mechanism: these profiles map controller combinations to keyboard shortcuts used by standalone emulators. That is why gamepad movement can work while an emulator action does not.

A short practice sequence before a long playthrough

Use a quiet overworld scene with no imminent battle or dialogue choice. Save normally first.

1. Movement: walk a short familiar path with normal controls. Confirm that A/B, shoulders, Start and Select still reach the actions your game uses.
2. Pause: try the documented pause/play combination and verify that the session resumes. This checks a low-stakes emulator action.
3. Display: try fullscreen and restore the original view. Check compact battle text afterward rather than optimizing from the title screen alone.
4. Speed: try fast-forward on that same path. Check normal-speed movement after releasing the input; record what your installed setup does.
5. Reopen: exit normally and relaunch through the same shortcut. Repeat one emulator action to check that the selected profile still applies.

Keep state loading out of this initial routine. Once menu access and harmless actions work, investigate save-state controls separately with disposable progress.

Troubleshoot the specific failure rather than resetting everything

Inspect the action that failed before changing unrelated emulator settings.

Worked example: a game works directly but not through ES-DE

Record both layout names, confirm that both paths use standalone mGBA, and inspect the frontend layer. Repeat the test with pause before fast-forward. If those harmless actions work after the profile correction, verify ordinary inputs and stop changing settings.

If the two routes also show different Continue progress, that is an additional save-location question. Keep it separate from the profile repair and preserve the original cartridge save.

After rebuilding a Steam entry, recheck its control path

A refreshed entry can solve a launch-target problem while leaving a separate control question. Keep the successful game output unchanged and identify the entry through which you are now playing. Check its selected profile before assuming the old shortcut’s arrangement followed automatically.

Example: a new plain-name test copy finally launches from Steam, but your usual fast-forward action no longer responds. Record the new entry and profile, then test pause or fullscreen. Repatching the unchanged game would not test this newly observed control difference.

Use the game-not-launching guide when the problem occurs before a title screen. Once it opens, return here for the input layer.

Keep pause, reset and stop distinct

The standalone mGBA reference assigns Select + A to Pause/Play, Select + L3 to Reset Emulation and Select + Start to Stop Emulation. The same hotkey table also lists holding L5 or R5 for stop. These actions depend on the documented Steam Input profile.

Choose pause when your immediate goal is to check whether the shortcut layer responds. Reset and stop are different actions, so do not use them interchangeably as an input test during unsaved play. Make a normal in-game save and preserve the intended checkpoint before testing session-ending controls.

Example: a customised layout makes a shoulder or grip action end the emulator unexpectedly. Inspect the active entry’s binding before changing game settings. Restore the intended layout, verify pause first, then check normal movement and menus. An accidental stop is a controls observation; it is not proof of a faulty patch.

Read the active layout before assuming these reference defaults apply. If reopening shows different progress, use the player-save guide. This section does not promise that stopping writes unsaved adventure progress.

The profile-selection and action-set steps above also use EmuDeck's primary hotkey documentation, checked 6 Oct 2026.

Documentation and scope

EmuDeck standalone mGBA hotkeys and Steam Input profiles, checked 6 Oct 2026. Steam Deck overview · GBA handheld setup.

Choose which layer you intend to change

Record the current bindings before changing them. If menu navigation already works, investigate the narrow game-control problem first.

Save a remap for one Pokémon game

1. Launch the intended game with the recorded mGBA core and open its Quick Menu.
2. Open Controls, inspect the player's controls and change one needed mapping.
3. Use Save Game Remap File for that game. Some installed menu layouts group save actions under remap-file management.
4. Resume and check movement, confirm, cancel, shoulders, Start and Select.
5. Close normally, launch the same file with the same core and repeat the input check.

Libretro documents core and game remaps. Use game scope for an initial experiment; choose core scope only if you deliberately want every game using that core to inherit it.

Why a different game can behave differently

Remaps have game, content-directory and core scopes. A narrower choice can sit above a broader one. If an arrangement seems to change between games, record the active file and existing remaps before overwriting them.

The remap directory is configurable under Settings → Directory → Input Remapping. Inspect your installed app's location instead of assuming a universal Android path. Preserve relevant remaps alongside your configuration backup.

Keep menu access and gameplay usable

Use a harmless menu or short walk to test each change. Keep the way back into RetroArch accessible, then verify the Pokémon actions you actually need. A convenient confirm button is not useful if it displaces a required shoulder action.

Try your own battle and party menus as well as movement.

Worked example: swap confirm and cancel only in one game

Launch that exact game, inspect its Quick Menu controls and record the original two assignments. Change them deliberately and save the game remap. Test a harmless Pokémon menu: select an option, return from it, then check normal movement.

Exit and reopen the same file with the same core. If the chosen arrangement remains, open another game using that core and inspect its ordinary controls.

Understand the input path before fixing a wrong button

Libretro's documented model is physical controller → virtual RetroPad → controls received by the core. Use that distinction to describe the problem precisely. “The A label is wrong” is less useful than “this physical button confirms in RetroArch but cancels inside the game.”

Use your actual observations in this record. The table does not prescribe a particular Pocket 5 face-button arrangement or claim which layout will be comfortable for you.

If the mapping disappears or affects another game

Check the exact content file and core first. A game-specific remap is a narrower setting than a core remap. Libretro also documents a content-directory scope, so a folder-level choice can matter when you compare games.

1. Identify the save action used: confirm whether you saved a game, directory or core remap. Record the current values before saving again.
2. Inspect existing scopes: preserve relevant files from the configured remap directory. A higher-scope assignment may still supply buttons you did not change.
3. Repeat on one known entry: launch the same game and core, change one needed assignment and use the intended game-save action.
4. Compare after relaunch: check that game and then another game using the same core. Record the result rather than overwriting every scope to make them match.

If you changed a ROM-hack filename or opened a second copy, note that difference before treating it as a persistence failure. Keep the old copy and its configuration available while checking which content entry you are launching.

Keep emulator actions away from ordinary game inputs

Game remapping and emulator hotkeys solve different problems. Libretro places hotkey configuration under Settings → Input → Hotkeys, and documents an Enable Hotkeys button that must be held for assigned actions when configured.

If an ordinary Pokémon button unexpectedly pauses or loads a state, investigate that emulator action separately from confirm/cancel mapping. Use a harmless scene and keep a known in-game save before changing shortcut bindings.

Do not copy the Miyoo MENU + SELECT combination or Steam Deck profile instructions into this Android setup. Use the menu access configured in your actual RetroArch installation. If it is already usable, preserve it while testing game controls.

Undo the narrow experiment before using a broad reset

Your recorded original assignments are the simplest rollback reference. Return the changed controls to those values and save at the same intended scope, then repeat the relaunch comparison. Keep backup remap files so you can inspect an older custom arrangement if needed.

A global reset affects more than the two buttons you were investigating. Start with the narrow game configuration. If the menu itself no longer responds, use the controller-input documentation and a working input method to regain navigation before attempting more game remaps.

Once controls work, verify your ordinary Pokémon Continue separately. A correct button layout does not establish that an imported cartridge save belongs to the game build; use the save-transfer checklist for that task.

Which saved file owns the change?

Libretro stores remaps as .rmp files, config overrides as .cfg and core options as .opt. These systems are separate. A saved configuration override is not evidence that you used the game-remap save action.

Example: you reversed two gameplay inputs, chose an unrelated save action and found the original controls after restarting. Return to the intended Controls remap procedure and its scope. Do not copy an ordinary save again or reset every emulator setting to solve a narrow persistence question.

Keep one short before/after record: exact content file, core, two changed actions, selected save scope and relaunch result. That is enough to compare the intended change without exporting a large configuration bundle. If you move devices, protect progress and settings as separate categories.

For Infinite Fusion in JoiPlay, use its own controller path. A RetroArch remap file does not configure another runtime.

Libretro configuration-file reference, checked 7 Oct 2026.

Check the game’s shoulder actions before borrowing a button

A Pokémon hack may use the GBA shoulders for convenience or information. Identify the action in the game first, then identify the physical button currently mapped to that GBA input. The printed shoulder label on an Android handheld alone does not tell you what the core receives.

Radical Red’s creator documents GBA L for a skills menu outside battle and for move information in battle. Inclement Emerald documents GBA R for auto-run. These are game actions; a remap that replaces them with another function can remove something useful even if confirm and cancel still work.

1. Read the exact game’s documented shoulder action.
2. Find the physical button delivering that GBA input through the current remap.
3. Test the action in the relevant scene, with emulator hotkeys inactive.
4. If changing the mapping, keep the displaced action reachable.
5. Save at game scope and repeat that action after relaunch.

Example: you can open the party menu, but cannot read Radical Red’s battle-move information after changing a shoulder assignment. Inspect the mapping delivering L before changing battle difficulty. If L works and a particular battle command is unavailable, investigate that game’s rules separately.

Use Radical Red’s information controls or Inclement Emerald’s preparation controls for the game-specific task.

A game remap can still inherit another button change

Libretro describes remaps as incremental: they store differences from preceding layers. A game file therefore does not necessarily cancel every core or folder assignment. A setting absent from that game file can remain inherited.

Worked example: imagine a core remap moved L to a different physical button, then your game remap changed only confirm and cancel. Confirm can now work exactly as intended while the shoulder action still follows the earlier assignment. The mere presence of a game remap is not evidence that L returned to its original button.

1. Write down two expected actions: confirm and the game's documented shoulder action.
2. Load the intended game and inspect both assignments in Quick Menu → Controls.
3. Correct the assignment you want this game to use, then save its game remap.
4. Close and reload the content; repeat both actions.
5. Open a second game using the same core to check the boundary of your change.

If the second game's behavior also needs changing, decide that explicitly before saving a broader remap. Keep a copy of the previous files so you can restore one scope at a time. For a game whose L action matters, use the shoulder-action examples above.

Libretro remap inheritance reference, checked 8 Oct 2026.

Buttons persist, but an emulator option changes after launch?

Game-specific core options use a different rule: Libretro describes them as full configurations loaded instead of the base options. They are separate from incremental remaps. The documented automatic-load setting is Load Content Specific Core Options Automatically under Configuration.

Example: your button experiment survives, but a separately changed emulator option does not. Record its value before and after opening the same content. Check the options file separately from the game remap. Avoid combining the experiments: first establish the working input result, then investigate the option through your installed version's core-options menu.

A file backup should retain the complete options file you intend to restore. Do not assume deleting a line behaves like removing one incremental button assignment. For the progress branch, follow the save-destination check.

Libretro core-options reference, checked 8 Oct 2026. Menu labels can differ by installed version.

Related software paths and primary references

Libretro input and control guide and remap scope and location reference, checked 6 Oct 2026.

Pocket 5 setup · GBA cartridge-save transfer · Separate melonDS Android save path.

Controls and save transfer are separate checks. No custom button layout, game performance or successful physical-unit remap was supplied to Pocket Deal Radar.