internal/gamepaddb: one bad token for another platform aborts the entire mapping update

Ebitengine Version

main @ 4f474b00d (after v2.9.11)

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (paste your go version output)

go version go1.26.7 linux/amd64

What steps will reproduce the problem?

1. Pass a community SDL game-controller database (via ebiten.UpdateStandardGamepadLayoutMappings) that contains a mapping line for a different platform, where that line also carries a token value the parser rejects — e.g. an unknown key such as hint:foo, or an SDL-legal hat token like +h0.1:

030000005e0400008e02000000000000,PS4 Controller,a:b0,b:b1,platform:Windows,hint:foo,

1. Call the update on Linux (or generally: a line whose platform: does not match the current OS, but which appears before the platform token in parse order carries a rejected value). The entire Update... call fails atomically, and all mappings — including the valid ones — are dropped, so gamepads stop working.

Root cause (internal/gamepaddb/gamepaddb.go:100-142 on current main): parseLine iterates tokens in order and calls parseMappingElement(tks[1]) at line 140 before ever seeing the platform token handled at lines 110-138. A single bad value token therefore return ..., err at line 142 even for lines that would have been skipped as foreign-platform, and Update (gamepaddb.go:541-556) aborts the whole database update. Relatedly, unknown keys are fatal instead of skipped, and SDL-legal notations (bN, +hX.Y) are rejected.

What is the expected result?

parseLine should determine the line's platform (and skip unknown keys) before parsing values, so foreign-platform lines and forward-compatible unknown keys can never veto the entire database. At minimum, one bad line must not invalidate all the good ones.

What happens instead?

Pasting a widely-shared community mapping DB — an officially encouraged workflow — can silently leave players with a completely non-functional gamepad, with the failure depending on database content rather than anything the player did. "Controller doesn't work at all" is a game-breaking experience for controller-centric games.

Anything else you feel useful to add?

• Severity: high for game users. The trigger (copy-pasting the community SDL DB) is common, the symptom (no gamepad input whatsoever) is total, and the cause (one foreign line) is invisible to both players and developers.
• Suggested fix: pre-scan for the platform token (skip non-matching lines early), continue on unknown keys instead of erroring, and accept SDL-legal value notations.