Add Steam Deck EmuDeck ES-DE support

[from-nibly]

Summary

This PR adds a Steam Deck-focused EmuDeck / ES-DE distribution for Grout. It introduces a new CFW=ESDE target that follows EmuDeck's standard folder layout and packages Grout as an ES-DE Port, so installation is the same style as the Batocera/ROCKNIX packages: unzip the release, then copy Grout.sh and the Grout/ folder into EmuDeck's roms/ports directory.

The new release asset is Grout-ESDE.zip, intended for Steam Deck users running EmuDeck with ES-DE.

What changed

• Added new ESDE CFW support:
  • ROMs: <Emulation>/roms
  • BIOS: <Emulation>/bios
  • Saves: <Emulation>/saves
  • Ports gamelist: <Emulation>/roms/ports/gamelist.xml
• Added ES-DE platform and initial save directory mappings.
• Added scripts/ESDE/Grout.sh launcher and packaging task.
• Added Grout-ESDE.zip to release workflow, versions.json asset generation, and in-app updater asset lookup.
• Added docs for Steam Deck / EmuDeck installation and ES-DE platform mappings.
• Bundled additional amd64 SDL/image/font transitive libraries needed on SteamOS.
• Added a Steam Deck / ES-DE input workaround:
  • ES-DE launcher uses direct Xbox-style face-button mapping.
  • ES-DE launcher disables duplicate keyboard/raw joystick input sources.
  • Grout ignores controller/joystick axis-motion events for ES-DE and detected Steam Deck hardware.

Steam Deck controls note

While testing on a Steam Deck with EmuDeck, SDL/Steam Input emitted a continuous stream of tiny analog-stick axis-motion events. This flooded SDL's event queue and caused controls to feel frozen, delayed, or to suddenly jump around. Ignoring axis-motion events fixed the issue in testing.

This appears related to the behavior reported in #216 (Steam Deck : Buttons response very weird) for Batocera on Steam Deck. This workaround is a little hacky because it disables analog-stick navigation on ES-DE / Steam Deck hardware, but Grout's UI is fully navigable with D-pad/buttons and this resolves the delayed/jittery control behavior we observed. If disabling axis-motion events is a concern, I am happy to adjust this to be controlled by an environment flag instead.

Validation

• go test ./... via nix-shell -p pkg-config SDL2 SDL2_image SDL2_ttf SDL2_gfx
• task build:amd64
• task package:esde
• Created and inspected dist/Grout-ESDE.zip
• uv run mkdocs build (passes with existing non-strict docs warnings)
• Installed and tested on a Steam Deck with EmuDeck from:
  /run/media/deck/.../Emulation/roms/ports/

Agent disclosure

This PR was implemented with assistance from an AI coding agent.

[from-nibly]

Sorry for the wall of text but I figured that's easier than having to grok the intent from the code.

I'm not sure if this is the right "fix" for the steam deck issue so let me know if you have any ideas on what the root cause would be but this does seem to work on the steam deck.

I have not tested this on batocera on steam deck but I did have the exact same issue on steamos as I had on batocera.

[pawndev]

hmm i remember doing something to disable some input in Grout for the miyoo flip
https://github.com/rommapp/grout/blob/main/app/setup.go#L124

is it not sufficient ?

[from-nibly]

@pawndev I still had the same input rubber banding issue on the latest grout version so I don't think that's sufficient.

[from-nibly]

OK sorry I'm such a flipping noob here, but this is what my agent is saying

That existing Miyoo Flip workaround handles duplicate keyboard/joystick input sources, and we do use the same idea in the ES-DE launcher. However, the Steam Deck issue appeared to be SDL queue flooding from continuous controller axis motion events. Filtering input after polling was not enough because the event loop still had to drain all of those axis events. Ignoring axis-motion event types at the SDL level fixed the rubberbanding in testing.

I'll test using the miyoo flip workaround though so we can be sure.