The_miro
/
sol-r1-linux-game-mappings
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
1 Commit
1 Branch
0 Tags
51 KiB
Python 90%
Shell 10%
 
 
Go to file
Amir Alexander Abdelbaki 79c9ed94c4 Add per-game Sol-R1 Linux input mapping system with reusable template 
Restructures around one folder per game, each with its own joyful
config, launch wrapper, and (if needed) a stateful daemon for physical
switches that need game-state feedback. template/ generalizes that
pattern (bare passthrough config, template wrapper, template daemon)
for mapping new games. space-engineers/ is the first instance, built
from the original mapping brief; find_codes.py is shared across games.
All device codes/keybinds/HUD calibration are still TODO pending
hardware access.
 		2026-07-13 10:19:27 +02:00
space-engineers Add per-game Sol-R1 Linux input mapping system with reusable template 2026-07-13 10:19:27 +02:00
template Add per-game Sol-R1 Linux input mapping system with reusable template 2026-07-13 10:19:27 +02:00
.gitignore Add per-game Sol-R1 Linux input mapping system with reusable template 2026-07-13 10:19:27 +02:00
README.md Add per-game Sol-R1 Linux input mapping system with reusable template 2026-07-13 10:19:27 +02:00
find_codes.py Add per-game Sol-R1 Linux input mapping system with reusable template 2026-07-13 10:19:27 +02:00

README.md

sol-r1-linux-game-mappings

Custom input mappings for the Thrustmaster Sol-R1 HOTAS (grip + base) on Linux (Arch/Hyprland), without Windows/T.A.R.G.E.T. Built on joyful, a Go-based Linux joystick remapper that turns physical Sol-R1 input into a virtual gamepad via YAML rules.

Layout

  • find_codes.py - shared diagnostic tool. Run against the physical hardware first, for any game, to get real evdev BTN_*/ABS_* codes to fill into that game's config.
  • template/ - starting point for mapping a new game: a bare passthrough joyful config (stick behaves normally, nothing remapped yet), a template Steam launch-options wrapper, and a template stateful input-converter daemon for controls that need game-state feedback (real on/off switches mapped to a game's stateless toggle key). See template/README.md.
  • <game>/ - one folder per game, each self-contained (its own joyful config, launch wrapper, and daemon + config if it needs one). Currently:
    • space-engineers/

Adding a new game

Copy template/ to <game-name>/ and follow template/README.md.

Why a daemon at all

joyful is stateless - it has no idea what's happening in the game, so it can only pass a control through or remap it. That's fine for buttons, triggers, and continuous axes. It breaks down for a real physical on/off switch mapped to a game action that's only exposed as a stateless "press to toggle" key: the switch position can silently drift out of sync with the game's actual state. Where that happens, a small per-game daemon polls both the physical switch and the game's actual state (usually by sampling a HUD pixel via grim, absent a better signal) and only sends a correction keypress when they disagree. See template/input_converter_daemon.py and space-engineers/switch_sync.py for a worked example.