Compare commits

..
Author SHA1 Message Date
enricobuehler 3b39710a5a fix(clients/android): controllers Android has no key layout for stop landing on the wrong buttons
ci / web (pull_request) Successful in 1m37s
ci / docs-site (pull_request) Successful in 1m43s
ci / bun-nix (pull_request) Successful in 30s
ci / docs-drift (pull_request) Successful in 27s
ci / rust-arm64 (pull_request) Successful in 2m19s
android / android (pull_request) Successful in 6m57s
ci / rust (pull_request) Successful in 7m23s
Reported from a Fire TV Stick 4K Max: a DualSense and an Xbox Elite Series 2,
both over Bluetooth, both identified correctly but with buttons on the wrong
actions ("L1 being L2"). Both work in Moonlight on the same box.

Android names a pad's buttons through a KEY LAYOUT file matched on VID/PID. A
pad with no matching file falls back to AOSP's `Generic.kl`, which assigns
keycodes by SCANCODE POSITION — 0x130→BUTTON_A, 0x131→BUTTON_B, 0x132→BUTTON_C
and up. That is only right if the pad's buttons sit where the file assumes, and
a HID gamepad with no kernel driver numbers its buttons 1..n straight through in
its OWN report order, so every keycode past the first divergence is somebody
else's button. Neither pad has a layout there: AOSP ships none for the Elite
Series 2 over Bluetooth (045e:0b05) on any version, and the DualSense's
(054c:0ce6) both postdates Fire OS and carries `requires_kernel_config
CONFIG_HID_PLAYSTATION`, which a Fire TV kernel has not. A DualSense reporting
straight through puts L2 on 0x136, which `Generic.kl` calls BUTTON_L1 — the
reported symptom exactly, and Circle and R1 (BUTTON_C / BUTTON_Z) mapped to
nothing at all and were dropped.

This client read `KeyEvent.keyCode` only, so it inherited every one of those
errors — in the stream, in the console shell's navigation, and in the
Controllers screen's own tester, which is why the tester agreed with the bug.

Resolve buttons from the SCANCODE instead, which is the pad's own report
position and immune to the layout file — the same reason `Keymap.toVk` reads
`scanCode` for keyboards. Two things keep it off pads that already work:

  1. the correction applies ONLY where the delivered keycode is what
     `Generic.kl` would have said, so a device-specific layout always wins;
  2. which report order to read is decided from what the DEVICE declares —
     a pad numbering straight through claims BUTTON_C and BUTTON_Z, keycodes
     no real controller has a button for — never from a model table.

`Gamepad.padKeyCode(event)` is a drop-in for `event.keyCode` and every pad
reader now goes through it: the streaming branch, the Skia console shell's
probe, the older Compose navigation, and the Controllers tester. The console and
the game must not disagree about which button a user pressed.

Axes get the same treatment: a pad declaring none of LTRIGGER/RTRIGGER,
BRAKE/GAS or BRAKE/THROTTLE is one Android never mapped, and its triggers are on
raw axes. A Sony pad reporting straight through lays out X, Y, Z, Rz, Rx, Ry, so
only the triggers (RX/RY) were missed; every other such pad puts the right stick
on Rx/Ry and the triggers on Z/Rz — the shape that makes pulling a trigger swing
the right stick. Whether those idle at −1 is measured off the device's own range
rather than assumed, so a pad reporting an honest 0..1 is not rescaled to a
permanent half-pull.

Also: the Controllers screen now reports each press as its raw scancode and
keycode plus the correction, names the resolved layout on the pad's card, and
reads axes through the same map the stream does — so it can be trusted again,
and so an unmapped pad can be pinned from a field report without the hardware.
The Xbox Bluetooth product ids (One S, Elite Series 2 and its Core) join the
identity table; without them an Elite streamed under the Xbox 360 identity.

Moonlight carries the same two report-order tables (`ControllerHandler`'s
`isNonStandardDualShock4` / `isNonStandardXboxBtController`), which is why both
pads work there on the same box.

Verified: :kit:testDebugUnitTest and :app:testDebugUnitTest both green (13 new
cases in PadButtonsTest covering the scancode tables and the axis resolution),
:app:compileDebugKotlin clean. NOT yet tested on glass — the reporter's Fire TV
is the confirmation this needs. The Xbox pad's Guide button stays unreachable
either way: it arrives as KEY_HOMEPAGE, and Android never delivers KEYCODE_HOME
to an app.
2026-08-20 18:46:56 +02:00
enricobuehler 19243c30b4 Merge pull request 'GameStream sessions built the XUSB pad that Steam cannot see — Xbox backend parity with the native plane' (#356) from worktree-gamestream-xbox-hid-parity into main
deb / build-publish-host (push) Successful in 5m28s
ci / bun-nix (push) Successful in 29s
ci / docs-drift (push) Successful in 50s
ci / docs-site (push) Successful in 1m18s
ci / web (push) Successful in 1m27s
ci / rust-arm64 (push) Successful in 1m55s
deb / build-publish-gamescope (push) Successful in 46s
docker / builders (--build-arg FEDORA_VERSION=44, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm, -f44) (push) Successful in 24s
docker / builders (ci/android-ci.Dockerfile, punktfunk-android-ci) (push) Successful in 20s
docker / builders (ci/arch-ci.Dockerfile, punktfunk-arch-ci) (push) Successful in 9s
docker / builders (ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 10s
docker / builders (ci/flatpak-ci.Dockerfile, punktfunk-flatpak-ci) (push) Successful in 10s
docker / builders (ci/gamescope-trixie.Dockerfile, punktfunk-gamescope-trixie) (push) Successful in 11s
docker / builders (ci/rust-ci-noble.Dockerfile, punktfunk-rust-ci-noble) (push) Successful in 10s
deb / build-publish-client-arm64 (push) Successful in 2m29s
docker / builders (ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 18s
deb / build-publish (push) Successful in 5m35s
docker / apps (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 2m4s
docker / apps (., web/Dockerfile, punktfunk-web) (push) Successful in 2m7s
docker / builders-arm64cross (push) Successful in 20s
docker / deploy-docs (push) Successful in 48s
ci / rust (push) Successful in 7m27s
android / android (push) Successful in 10m54s
deb / smoke-install (push) Successful in 3m58s
arch / build-publish (push) Successful in 11m11s
windows-host / package (push) Successful in 14m38s
windows-host / winget-source (push) Skipped
windows-host / canary-manifest (push) Successful in 34s
rpm / build-publish (44, fedora-44, punktfunk-fedora44-rpm) (push) Successful in 19m16s
rpm / build-publish (43, bazzite, punktfunk-fedora-rpm) (push) Successful in 19m13s
2026-08-20 16:33:41 +00:00
enricobuehler dfcffcdd50 fix(gamestream/windows): Moonlight sessions built the XUSB pad that Steam cannot see
ci / bun-nix (pull_request) Successful in 36s
ci / docs-drift (pull_request) Successful in 35s
ci / web (pull_request) Successful in 1m36s
ci / docs-site (pull_request) Successful in 1m37s
ci / rust-arm64 (pull_request) Successful in 1m39s
ci / rust (pull_request) Successful in 5m36s
android / android (pull_request) Successful in 5m51s
Reported from the field: gamepad input does nothing on GameStream clients, and it
reproduces across every client and device a user tries (Artemis on a Steam Deck and
on an Android phone both). That breadth is the tell — it is not a client at all.

On Windows there are two virtual Xbox backends and they are not interchangeable to a
game. The XUSB companion registers only GUID_DEVINTERFACE_XUSB and exposes no HID
collection (pf_xusb.inx says so in its own header: "a non-HID UMDF2 driver", Class =
System), so Steam's hidapi enumeration, SDL, RawInput, DirectInput, joy.cpl and
WGI/GameInput cannot see it at all — only classic XInputGetState can. The native plane
moved to the real HID pad as its DEFAULT on 2026-08-09 (bd5735b8) for exactly that
reason; its doc comment records the reporter who lost a controller for two weeks to it.

The GameStream plane never got that change. It has bound `crate::inject::gamepad`
since the first gamepad commit, when that name meant uinput and Windows had no second
backend; Windows later gave the same name the XUSB companion, so this plane inherited
it by module-name coincidence rather than by any decision. bd5735b8 did touch
control.rs — but only to widen the rumble closure's arity, and its note reasons about
"the uinput backend", not about the Windows one sitting behind the same import. So
every Moonlight session since has presented a pad most games cannot enumerate, while
native punktfunk sessions on the same host got the good one.

There was also no way out: `windows_xbox_hid` was `pub(super)`, i.e. unreachable from
this module, so PUNKTFUNK_XBOX_BACKEND did nothing here — and the Windows manager
ignores the arrival `kind` byte, so a client could not ask for a DualSense either, the
escape that saved the earlier reporter.

- native.rs / native/gamepad.rs: `mod gamepad` and `windows_xbox_hid` become
  pub(crate). The knob keeps ONE definition and one name; widening visibility breaks
  no existing caller. Its doc now records that both planes read it, and why being
  `pub(super)` was itself the bug.
- gamestream/control.rs: a `SessionPads` enum is the one place this plane picks a
  backend — the HID pad when the shared knob says so, the XUSB companion otherwise,
  and on every other platform the single backend that exists.
  `PUNKTFUNK_XBOX_BACKEND=xusb` now reverts both planes together.

The HID pad's rich-feedback plane is dropped rather than plumbed: an Xbox pad has no
lightbar or adaptive triggers, and GameStream has no vocabulary for one — its rumble
message (0x010B) carries the two handle motors and nothing else, which is why the
trigger levels were already dropped at the call site.

No test: a `cfg(target_os = "windows")` #[test] would compile NOWHERE. ci.yml excludes
it by target, and windows-host.yml lints the host with `cargo clippy -p punktfunk-host`
without `--all-targets`, which does not build `cfg(test)` modules at all — the same
blind spot that workflow's own comments blame for letting the Linux twin's tests rot to
the wrong arity. It would be dead weight, not coverage.

VERIFIED
  * ON WINDOWS (.133, the only box where this arm compiles at all):
    `cargo check -p punktfunk-host` clean in 57s, then
    `cargo clippy -p punktfunk-host -- -D warnings` clean in 42s — both on default
    features, which include `gamestream`. This compiles BOTH enum arms: `Xusb` and
    `Hid` are Windows types alike.
    Non-vacuous by construction: `cargo clean -p punktfunk-host` ran first (a scp'd
    tree plus this box's lagging clock and a warm shared target dir otherwise yield a
    fresh `Finished` having compiled nothing), and both passes logged
    `Compiling punktfunk-host v0.31.0`. The only warning is punktfunk-core's
    header-write notice — benign and pre-existing.
  * `cargo fmt --all --check` clean.

NOT VERIFIED — owed
  * Linux: no box could run it (.25's root filesystem is 100% full; .21/.136/.138 were
    down; OrbStack here hangs even on `docker run alpine echo`). Exposure is small —
    the Linux arm is three calls on a `GamepadManager` whose Windows XUSB sibling has
    the identical method surface and just compiled — and ci.yml DOES run on
    pull_request, so opening a PR closes this.
  * On glass: no Moonlight session has driven the HID pad through this plane yet. That
    is the real acceptance test, and the log line to look for is
    "virtual Xbox pad created (Windows UMDF HID)" where it used to say
    "virtual Xbox 360 created (Windows XUSB companion)".
  * windows-host.yml has NO `pull_request` trigger (push to main, v* tags,
    workflow_dispatch only), so CI will not re-check this arm on a PR — the .133 run
    above is deliberately standing in for it.
2026-08-20 18:19:19 +02:00
enricobuehler f2b5b3e567 Merge pull request '0.31.0 release notes, re-cut on current main — and the bun install CI flake' (#351) from worktree-release-next-prep into main
ci / bun-nix (push) Successful in 26s
ci / docs-drift (push) Successful in 29s
ci / docs-site (push) Successful in 1m22s
ci / web (push) Successful in 2m13s
ci / rust-arm64 (push) Successful in 2m35s
windows-client / client (arm64, --no-default-features, aarch64-pc-windows-msvc, C:\t-a64) (push) Successful in 4m5s
android-screenshots / screenshots (push) Successful in 2m12s
ci / rust (push) Successful in 8m26s
decky / build-publish (push) Successful in 41s
windows-client / client (x64, , x86_64-pc-windows-msvc, C:\t) (push) Successful in 8m37s
android / android (push) Successful in 9m57s
linux-client-screenshots / screenshots (push) Successful in 2m32s
sbom / sbom (push) Successful in 26s
arch / build-publish (push) Successful in 10m14s
flatpak / build-publish (push) Successful in 5m2s
docker / builders-arm64cross (push) Successful in 13s
docker / builders (--build-arg FEDORA_VERSION=44, ci/fedora-rpm.Dockerfile, punktfunk-fedora44-rpm, -f44) (push) Successful in 8s
docker / builders (ci/android-ci.Dockerfile, punktfunk-android-ci) (push) Successful in 10s
docker / builders (ci/arch-ci.Dockerfile, punktfunk-arch-ci) (push) Successful in 10s
docker / builders (ci/fedora-rpm.Dockerfile, punktfunk-fedora-rpm) (push) Successful in 11s
docker / builders (ci/flatpak-ci.Dockerfile, punktfunk-flatpak-ci) (push) Successful in 13s
docker / builders (ci/gamescope-trixie.Dockerfile, punktfunk-gamescope-trixie) (push) Successful in 13s
docker / builders (ci/rust-ci-noble.Dockerfile, punktfunk-rust-ci-noble) (push) Successful in 13s
docker / builders (ci/rust-ci.Dockerfile, punktfunk-rust-ci) (push) Successful in 16s
docker / apps (., web/Dockerfile, punktfunk-web) (push) Successful in 1m11s
docker / apps (docs-site, docs-site/Dockerfile, punktfunk-docs) (push) Successful in 29s
docker / deploy-docs (push) Successful in 17s
deb / smoke-install (push) Successful in 4m40s
deb / build-publish (push) Successful in 3m24s
deb / build-publish-host (push) Successful in 7m31s
deb / build-publish-gamescope (push) Successful in 22s
deb / build-publish-client-arm64 (push) Successful in 1m11s
web-screenshots / screenshots (push) Successful in 6m19s
windows-host / package (push) Successful in 13m57s
windows-host / canary-manifest (push) Skipped
windows-host / winget-source (push) Successful in 19s
rpm / build-publish (44, fedora-44, punktfunk-fedora44-rpm) (push) Successful in 17m11s
rpm / build-publish (43, bazzite, punktfunk-fedora-rpm) (push) Successful in 19m43s
apple / swift (push) Failing after 18s
apple / distribute (push) Skipped
apple / screenshots (push) Skipped
2026-08-20 07:50:58 +00:00
10 changed files with 694 additions and 55 deletions
@@ -136,14 +136,19 @@ internal fun ControllersScreen(
// Read ONCE, up front: the test can end inside this very event, and the release that
// ended it still has to be swallowed here — see the B branch below.
val consume = consuming
// The CORRECTED keycode, so this screen shows the button the stream will send and not
// the one Android guessed for a pad it has no key layout for — the two differ on every
// controller [Gamepad.padKeyCode] exists for, and a tester that disagrees with the
// stream is worse than no tester. The raw pair is still reported in "Last input".
val code = Gamepad.padKeyCode(event)
when (event.action) {
KeyEvent.ACTION_DOWN -> {
held[event.keyCode] = true
if (event.keyCode == KeyEvent.KEYCODE_BUTTON_B) bHeld = true
held[code] = true
if (code == KeyEvent.KEYCODE_BUTTON_B) bHeld = true
}
KeyEvent.ACTION_UP -> {
held[event.keyCode] = false
if (event.keyCode == KeyEvent.KEYCODE_BUTTON_B) {
held[code] = false
if (code == KeyEvent.KEYCODE_BUTTON_B) {
bHeld = false
if (consume) {
if (event.eventTime - event.downTime >= HOLD_TO_FINISH_MS) {
@@ -167,23 +172,43 @@ internal fun ControllersScreen(
}
}
}
lastInput = "${event.device?.name}: ${KeyEvent.keyCodeToString(event.keyCode)}"
// Raw scancode AND keycode, plus the correction when one fired: this line is what a
// field report needs to pin an unmapped pad's report order without the device in hand.
val raw = KeyEvent.keyCodeToString(event.keyCode).removePrefix("KEYCODE_")
val fixed = KeyEvent.keyCodeToString(code).removePrefix("KEYCODE_")
lastInput = "${event.device?.name}: scan 0x%X · %s%s".format(
event.scanCode,
raw,
if (code != event.keyCode) "$fixed" else "",
)
consume
}
val motionProbe: (MotionEvent) -> Boolean = probe@{ event ->
if (!Gamepad.isPad(event.device)) return@probe false
// Through the device's resolved map, exactly as `Gamepad.AxisMapper` reads it while
// streaming — on a pad Android has no key layout for, the right stick and the triggers
// are not on the axes their names suggest.
val map = Gamepad.padMap(event.device)
axes["LX"] = event.getAxisValue(MotionEvent.AXIS_X)
axes["LY"] = event.getAxisValue(MotionEvent.AXIS_Y)
axes["RX"] = event.getAxisValue(MotionEvent.AXIS_Z)
axes["RY"] = event.getAxisValue(MotionEvent.AXIS_RZ)
axes["LT"] = maxOf(
event.getAxisValue(MotionEvent.AXIS_LTRIGGER),
event.getAxisValue(MotionEvent.AXIS_BRAKE),
)
axes["RT"] = maxOf(
event.getAxisValue(MotionEvent.AXIS_RTRIGGER),
event.getAxisValue(MotionEvent.AXIS_GAS),
)
axes["RX"] = event.getAxisValue(map.rightStickX)
axes["RY"] = event.getAxisValue(map.rightStickY)
axes["LT"] = if (map.leftTrigger == Gamepad.AXIS_NONE) {
maxOf(
event.getAxisValue(MotionEvent.AXIS_LTRIGGER),
event.getAxisValue(MotionEvent.AXIS_BRAKE),
)
} else {
map.level(event.getAxisValue(map.leftTrigger))
}
axes["RT"] = if (map.rightTrigger == Gamepad.AXIS_NONE) {
maxOf(
event.getAxisValue(MotionEvent.AXIS_RTRIGGER),
event.getAxisValue(MotionEvent.AXIS_GAS),
)
} else {
map.level(event.getAxisValue(map.rightTrigger))
}
axes["HX"] = event.getAxisValue(MotionEvent.AXIS_HAT_X)
axes["HY"] = event.getAxisValue(MotionEvent.AXIS_HAT_Y)
consuming
@@ -689,6 +714,16 @@ private fun PadRow(info: PadInfo, gamepadSetting: Int) {
style = MaterialTheme.typography.bodySmall,
color = MaterialTheme.colorScheme.onSurfaceVariant,
)
// Only when a correction is actually in force: on a pad Android has a key layout for
// there is nothing to say, and a line that says "normal" on every device teaches
// nobody anything. Named rather than merely flagged, so a field report can quote it.
padButtonsNote(info.buttons)?.let {
Text(
it,
style = MaterialTheme.typography.bodySmall,
color = MaterialTheme.colorScheme.onSurfaceVariant,
)
}
if (info.canRumble) {
OutlinedButton(onClick = { info.dev?.let(::testRumble) }) { Text("Test rumble") }
} else {
@@ -784,6 +819,12 @@ internal data class PadInfo(
val controllerNumber: Int,
val resolvedPref: Int,
val canRumble: Boolean,
/**
* The report order this pad's buttons were resolved to ([Gamepad.padButtons]). Defaults to
* the pad Android already knows, which is what a screenshot scene wants and what the note
* under the card stays silent about.
*/
val buttons: Gamepad.PadButtons = Gamepad.PadButtons.NATIVE,
val dev: InputDevice? = null,
)
@@ -793,6 +834,7 @@ internal fun padInfoOf(dev: InputDevice): PadInfo = PadInfo(
forwarded = isForwarded(dev),
controllerNumber = dev.controllerNumber,
resolvedPref = Gamepad.prefFor(dev),
buttons = Gamepad.padMap(dev).buttons, // via padMap so the list refresh reuses the cache
canRumble = deviceHasVibrator(dev),
dev = dev,
)
@@ -823,6 +865,20 @@ internal fun testRumble(dev: InputDevice) {
}
/** Identity line: VID:PID + the source classes Android assigned. */
/**
* What to say about a pad whose buttons had to be resolved from their scancodes because Android
* has no key layout for it — null for a pad it does know, which needs no explanation.
*/
private fun padButtonsNote(buttons: Gamepad.PadButtons): String? = when (buttons) {
Gamepad.PadButtons.NATIVE -> null
Gamepad.PadButtons.GENERIC_SONY ->
"Android has no button layout for this controller — read as a PlayStation pad"
Gamepad.PadButtons.GENERIC_XBOX ->
"Android has no button layout for this controller — read as an Xbox pad"
Gamepad.PadButtons.SONY_MODERN ->
"Android has no button layout for this controller — face buttons corrected"
}
private fun deviceDetail(dev: InputDevice): String =
"%04X:%04X · %s".format(dev.vendorId, dev.productId, sourcesLabel(dev.sources))
@@ -11,6 +11,7 @@ import androidx.compose.runtime.getValue
import androidx.compose.runtime.remember
import androidx.compose.runtime.rememberUpdatedState
import androidx.compose.ui.platform.LocalContext
import io.unom.punktfunk.kit.Gamepad
import kotlin.math.abs
import kotlinx.coroutines.delay
import kotlinx.coroutines.isActive
@@ -96,7 +97,7 @@ fun GamepadNavEffect(
val keyProbe: (KeyEvent) -> Boolean = probe@{ ev ->
val down = ev.action == KeyEvent.ACTION_DOWN
val edge = down && ev.repeatCount == 0
when (ev.keyCode) {
when (Gamepad.padKeyCode(ev)) {
KeyEvent.KEYCODE_DPAD_LEFT -> { state.dpadX = if (down) -1 else 0; true }
KeyEvent.KEYCODE_DPAD_RIGHT -> { state.dpadX = if (down) 1 else 0; true }
// TV remote (no face buttons): Up → Settings, Down → a saved host's Options.
@@ -202,7 +203,7 @@ fun GamepadNavEffect2D(
val keyProbe: (KeyEvent) -> Boolean = probe@{ ev ->
val down = ev.action == KeyEvent.ACTION_DOWN
val edge = down && ev.repeatCount == 0
when (ev.keyCode) {
when (Gamepad.padKeyCode(ev)) {
KeyEvent.KEYCODE_DPAD_LEFT -> { state.dpadX = if (down) -1 else 0; true }
KeyEvent.KEYCODE_DPAD_RIGHT -> { state.dpadX = if (down) 1 else 0; true }
KeyEvent.KEYCODE_DPAD_UP -> { state.dpadY = if (down) -1 else 0; true }
@@ -616,7 +616,7 @@ class MainActivity : ComponentActivity() {
// no BUTTON_SELECT scancode delivers its Select: see [Gamepad.padButtonBit], which is
// why this asks it rather than `buttonBit`).
if (event.isFromSource(InputDevice.SOURCE_GAMEPAD)) {
val bit = Gamepad.padButtonBit(event.keyCode, event.flags)
val bit = Gamepad.padButtonBit(Gamepad.padKeyCode(event), event.flags)
if (bit != 0) {
// The router forwards the bit on this device's own wire pad index and tracks held
// state per pad. The emergency-exit chord (Select + Start + L1 + R1) is handled
@@ -708,8 +708,10 @@ class MainActivity : ComponentActivity() {
if (event.isFromSource(InputDevice.SOURCE_GAMEPAD)) {
// Not streaming: a game controller drives the Compose UI (TV + phone). Map the face
// buttons to the navigation the focus system / back stack understand; D-pad *keys*
// already move focus on their own, so they fall through to super untouched.
when (event.keyCode) {
// already move focus on their own, so they fall through to super untouched. Read
// through [Gamepad.padKeyCode] so a pad Android has no key layout for reaches the
// menus on the right buttons too, not only the stream.
when (Gamepad.padKeyCode(event)) {
// B → back. Drive the OnBackPressedDispatcher directly rather than synthesising a
// BACK KeyEvent: a synthetic event isn't "tracking", so the framework's default
// onKeyUp(BACK) never calls onBackPressed() and Compose BackHandlers wouldn't fire.
@@ -159,7 +159,12 @@ fun SkiaConsoleShell(
if (ev.action != KeyEvent.ACTION_DOWN && ev.action != KeyEvent.ACTION_UP) return@probe false
val fromPad = ev.isFromSource(InputDevice.SOURCE_GAMEPAD)
if (fromPad) {
val bit = when (ev.keyCode) {
// The CORRECTED keycode: a pad Android has no key layout for delivers its buttons
// under other buttons' names, so read raw this console answered ✕ with whatever
// sat in BUTTON_A's scancode slot. Same resolution the stream uses — the console
// and the game must not disagree about which button a user pressed.
val code = Gamepad.padKeyCode(ev)
val bit = when (code) {
KeyEvent.KEYCODE_BUTTON_A -> 0
KeyEvent.KEYCODE_BUTTON_B -> 1
KeyEvent.KEYCODE_BUTTON_X -> 2
@@ -179,7 +184,7 @@ fun SkiaConsoleShell(
}
return@probe true
}
val dbit = when (ev.keyCode) {
val dbit = when (code) {
KeyEvent.KEYCODE_DPAD_UP -> 0
KeyEvent.KEYCODE_DPAD_DOWN -> 1
KeyEvent.KEYCODE_DPAD_LEFT -> 2
@@ -191,7 +196,7 @@ fun SkiaConsoleShell(
padState.push(handle)
return@probe true
}
if (ev.keyCode == KeyEvent.KEYCODE_BUTTON_SELECT && down && ev.repeatCount == 0) {
if (code == KeyEvent.KEYCODE_BUTTON_SELECT && down && ev.repeatCount == 0) {
NativeBridge.nativeConsoleMenu(handle, 0) // ▲ opens the tile's options on Home
return@probe true
}
@@ -3,6 +3,7 @@ package io.unom.punktfunk.kit
import android.view.InputDevice
import android.view.KeyEvent
import android.view.MotionEvent
import java.util.concurrent.ConcurrentHashMap
import kotlin.math.roundToInt
/**
@@ -127,8 +128,12 @@ object Gamepad {
// Microsoft Xbox One / Series product ids (wired + the common Bluetooth/dongle revisions). All
// behave like Xbox 360 on the host minus the glyph identity, so they share one pref byte.
// The Bluetooth revisions (0x02E0/0x02FD Xbox One S, 0x0B05/0x0B22 Elite Series 2 and its
// Core) are here for the same reason as the wired ones: they are the pads a couch actually
// pairs to a TV box, and without them an Elite streams under the Xbox 360 identity.
private val PID_XBOXONE = setOf(
0x02D1, 0x02DD, 0x02E3, 0x02EA, 0x0B00, 0x0B12, 0x0B13, 0x0B20,
0x02D1, 0x02DD, 0x02E0, 0x02E3, 0x02EA, 0x02FD,
0x0B00, 0x0B05, 0x0B12, 0x0B13, 0x0B20, 0x0B22,
)
/**
@@ -293,6 +298,303 @@ object Gamepad {
else -> BTN_BACK
}
// ---------------------------------------------------------------------------------------
// Controllers Android has no key layout for
//
// Android turns a pad's raw evdev scancode into a `KeyEvent.keyCode` through a KEY LAYOUT
// file matched on USB VID/PID (`Vendor_054c_Product_0ce6.kl` & co.). A pad with no matching
// file falls back to AOSP's `Generic.kl`, which assigns keycodes by SCANCODE POSITION —
// `0x130`→BUTTON_A, `0x131`→BUTTON_B, `0x132`→BUTTON_C, and so on up. That is only right if
// the pad's buttons happen to sit at the positions the file assumes, and a HID gamepad with
// no kernel driver behind it numbers its buttons 1..n straight through IN ITS OWN REPORT
// ORDER — so every keycode after the first divergence is somebody else's button.
//
// Reported from a Fire TV Stick 4K Max (2026-08-20): a DualSense and an Xbox Elite Series 2,
// both over Bluetooth, both identified correctly but with buttons landing on the wrong
// actions ("L1 being L2"). Neither has a layout there — AOSP ships none for the Elite
// Series 2 over Bluetooth (`045e:0b05`) on ANY version, and the DualSense's
// (`054c:0ce6`) both postdates Fire OS and carries `requires_kernel_config
// CONFIG_HID_PLAYSTATION`, which a Fire TV kernel does not have. A DualSense reporting
// straight through puts L2 on `0x136`, which `Generic.kl` calls BUTTON_L1: the reported
// symptom exactly.
//
// The fix is to resolve buttons from the SCANCODE, which is the pad's own report position and
// is immune to the layout file — the same reason [Keymap.toVk] reads `scanCode` for keyboards.
// Two things keep it from breaking a pad that already works:
//
// 1. The correction is applied ONLY when the delivered keycode is what `Generic.kl` would
// have said ([genericKeyCode]). A different keycode means a device-specific layout IS in
// force and already knows this pad better than we do, so we leave it alone.
// 2. Which report order to read is decided from what the DEVICE declares, never a model
// table: a pad numbering straight through claims BUTTON_C and BUTTON_Z ([PadButtons]),
// keycodes no real controller has a button for.
//
// Moonlight carries the same two tables (`ControllerHandler`'s `isNonStandardDualShock4` /
// `isNonStandardXboxBtController`), which is why both pads work there on the same box.
/** [MotionEvent] axis id meaning "this pad has no such axis" — see [PadMap]. */
const val AXIS_NONE = -1
/**
* The report order a controller's buttons are numbered in, and with it which scancode carries
* which physical button. Resolved once per device by [padButtons] from what the device
* declares; [correct] then maps one scancode to the keycode it should have produced.
*/
enum class PadButtons {
/**
* The keycode Android delivered is already right a device-specific key layout is in
* force, or the generic one happens to agree. [correct] changes nothing.
*/
NATIVE,
/**
* A Sony pad numbering straight through with no kernel driver behind it: L1 R1
* L2 R2 Create Options L3 R3 PS, i.e. `0x130`..`0x13c` in that order. The analog trigger
* value rides `AXIS_RX`/`AXIS_RY` on such a pad, so the digital L2/R2 fold to keycodes
* [buttonBit] deliberately drops the wire carries the axis, never both.
*/
GENERIC_SONY,
/**
* An Xbox-layout pad numbering straight through: A B X Y LB RB View Menu LS RS, i.e.
* `0x130`..`0x139`. Also the fallback for an unbranded pad, which near-universally
* clones the Xbox layout the same assumption [styleFor] makes for its glyphs.
*/
GENERIC_XBOX,
/**
* A Sony pad WITH a kernel driver (`hid-playstation` / `hid-sony`) but still no key
* layout the combination an Android 11 box on a 5.10 kernel lands in. Such a driver
* emits the modern Linux gamepad codes, where `0x133` is BTN_NORTH () and `0x134` is
* BTN_WEST (); `Generic.kl` reads those two as BUTTON_X and BUTTON_Y, so exactly the
* face pair comes out swapped and nothing else is wrong.
*/
SONY_MODERN,
;
/**
* The keycode scancode [scan] should have produced, given Android delivered [keyCode].
*
* Returns [keyCode] untouched unless it is precisely what [genericKeyCode] would have
* said for [scan] anything else is a device-specific layout's answer, which outranks
* this table. That guard is what makes the correction idempotent and safe to run on
* every pad: it can only ever fire where Android was guessing in the first place.
*/
fun correct(scan: Int, keyCode: Int): Int {
if (this == NATIVE) return keyCode
if (keyCode != genericKeyCode(scan)) return keyCode
val fixed = when (this) {
GENERIC_SONY -> when (scan) {
0x130 -> KeyEvent.KEYCODE_BUTTON_X // □
0x131 -> KeyEvent.KEYCODE_BUTTON_A // ✕
0x132 -> KeyEvent.KEYCODE_BUTTON_B // ○
0x133 -> KeyEvent.KEYCODE_BUTTON_Y // △
0x134 -> KeyEvent.KEYCODE_BUTTON_L1
0x135 -> KeyEvent.KEYCODE_BUTTON_R1
0x136 -> KeyEvent.KEYCODE_BUTTON_L2 // analog: AXIS_RX
0x137 -> KeyEvent.KEYCODE_BUTTON_R2 // analog: AXIS_RY
0x138 -> KeyEvent.KEYCODE_BUTTON_SELECT // Create / Share
0x139 -> KeyEvent.KEYCODE_BUTTON_START // Options
0x13a -> KeyEvent.KEYCODE_BUTTON_THUMBL
0x13b -> KeyEvent.KEYCODE_BUTTON_THUMBR
0x13c -> KeyEvent.KEYCODE_BUTTON_MODE // PS
// 0x13d touchpad click / 0x13e mute: no wire button, dropped as before.
else -> KeyEvent.KEYCODE_UNKNOWN
}
GENERIC_XBOX -> when (scan) {
0x132 -> KeyEvent.KEYCODE_BUTTON_X
0x133 -> KeyEvent.KEYCODE_BUTTON_Y
0x134 -> KeyEvent.KEYCODE_BUTTON_L1
0x135 -> KeyEvent.KEYCODE_BUTTON_R1
0x136 -> KeyEvent.KEYCODE_BUTTON_SELECT // View
0x137 -> KeyEvent.KEYCODE_BUTTON_START // Menu
0x138 -> KeyEvent.KEYCODE_BUTTON_THUMBL
0x139 -> KeyEvent.KEYCODE_BUTTON_THUMBR
else -> keyCode // 0x130 A / 0x131 B already agree
}
// Only the face pair; every other row of Generic.kl is right for these codes.
SONY_MODERN -> when (scan) {
0x133 -> KeyEvent.KEYCODE_BUTTON_Y // BTN_NORTH = △
0x134 -> KeyEvent.KEYCODE_BUTTON_X // BTN_WEST = □
else -> keyCode
}
NATIVE -> keyCode
}
return fixed
}
}
/**
* AOSP `Generic.kl`'s gamepad rows the layout Android falls back to when no device-specific
* key layout matches the pad's VID/PID. Scancodes outside it answer [KeyEvent.KEYCODE_UNKNOWN],
* which never equals a real delivered keycode, so [PadButtons.correct]'s guard leaves those
* events alone.
*/
fun genericKeyCode(scan: Int): Int = when (scan) {
0x130 -> KeyEvent.KEYCODE_BUTTON_A
0x131 -> KeyEvent.KEYCODE_BUTTON_B
0x132 -> KeyEvent.KEYCODE_BUTTON_C
0x133 -> KeyEvent.KEYCODE_BUTTON_X
0x134 -> KeyEvent.KEYCODE_BUTTON_Y
0x135 -> KeyEvent.KEYCODE_BUTTON_Z
0x136 -> KeyEvent.KEYCODE_BUTTON_L1
0x137 -> KeyEvent.KEYCODE_BUTTON_R1
0x138 -> KeyEvent.KEYCODE_BUTTON_L2
0x139 -> KeyEvent.KEYCODE_BUTTON_R2
0x13a -> KeyEvent.KEYCODE_BUTTON_SELECT
0x13b -> KeyEvent.KEYCODE_BUTTON_START
0x13c -> KeyEvent.KEYCODE_BUTTON_MODE
0x13d -> KeyEvent.KEYCODE_BUTTON_THUMBL
0x13e -> KeyEvent.KEYCODE_BUTTON_THUMBR
else -> KeyEvent.KEYCODE_UNKNOWN
}
/**
* How one controller must be read: its button report order plus the axes its right stick and
* analog triggers actually arrive on. Resolved once per device by [padMap].
*/
class PadMap(
val buttons: PadButtons,
val rightStickX: Int = MotionEvent.AXIS_Z,
val rightStickY: Int = MotionEvent.AXIS_RZ,
/**
* The trigger axes, or [AXIS_NONE] for a pad Android already names them on that case
* keeps folding LTRIGGER with BRAKE and RTRIGGER with GAS by max, which is what pads that
* report one pair, the other, or both have always needed.
*/
val leftTrigger: Int = AXIS_NONE,
val rightTrigger: Int = AXIS_NONE,
/** Those trigger axes rest at 1 rather than 0, measured off the device's own range. */
val triggersSigned: Boolean = false,
) {
/** One resolved trigger axis value, folded to the 0..1 the wire scale expects. */
fun level(v: Float): Float = if (triggersSigned) (v + 1f) / 2f else v
}
/** The map every pad with a key layout uses: Android's own names, unchanged. */
private val NATIVE_MAP = PadMap(PadButtons.NATIVE)
/**
* Resolved [PadMap]s, keyed by [InputDevice.getDescriptor] the device's stable identity
* hash, so a pad that reconnects is recognised and a model resolves once for the process.
* Nothing here depends on a live connection, so entries never need evicting.
*/
private val padMaps = ConcurrentHashMap<String, PadMap>()
/**
* Which report order [dev]'s buttons follow, asked of the device rather than a model table.
*
* A pad numbering its HID buttons straight through reaches BUTTON_C and BUTTON_Z, keycodes
* that exist only as `Generic.kl` positions no controller has a physical C or Z button, and
* a pad with a kernel driver behind it emits the modern Linux gamepad codes, which skip both.
* Declaring the pair is therefore the signature of a pad Android is guessing at.
*/
fun padButtons(dev: InputDevice): PadButtons {
val has = dev.hasKeys(KeyEvent.KEYCODE_BUTTON_C, KeyEvent.KEYCODE_BUTTON_Z, 0)
val straightThrough = has[0] && has[1]
return when {
straightThrough && dev.vendorId == VID_SONY -> PadButtons.GENERIC_SONY
straightThrough -> PadButtons.GENERIC_XBOX
dev.vendorId == VID_SONY -> PadButtons.SONY_MODERN
else -> PadButtons.NATIVE
}
}
/**
* The [PadMap] for [dev] its button report order and the axes its right stick and triggers
* arrive on, resolved once per device model and cached.
*
* Axes get the same treatment as buttons: a pad Android has a layout for names its triggers
* LTRIGGER/RTRIGGER (or BRAKE/GAS, or BRAKE/THROTTLE) and is left exactly as it was. A pad
* with NONE of those names is one Android never mapped, and its triggers are sitting on two
* raw axes under the names the HID report gave them. Which two depends on the same report
* order the buttons did:
*
* - a Sony pad reporting straight through lays out X, Y, Z, Rz, Rx, Ry = left stick, right
* stick, then the triggers so the right stick is already right and only the triggers
* (`AXIS_RX`/`AXIS_RY`) are missed;
* - every other such pad puts the right stick on Rx/Ry and the triggers on Z/Rz, which is
* the shape that makes pulling a trigger swing the right stick.
*
* Whether those axes idle at 1 is MEASURED from the device's own range rather than assumed,
* so a pad that reports an honest 0..1 is not rescaled to a permanent half-pull.
*/
fun padMap(dev: InputDevice?): PadMap {
if (dev == null) return NATIVE_MAP
padMaps[dev.descriptor]?.let { return it }
val buttons = padButtons(dev)
fun has(a: Int) = axis(dev, a) != null
val named = (has(MotionEvent.AXIS_LTRIGGER) && has(MotionEvent.AXIS_RTRIGGER)) ||
(has(MotionEvent.AXIS_BRAKE) && has(MotionEvent.AXIS_GAS)) ||
(has(MotionEvent.AXIS_BRAKE) && has(MotionEvent.AXIS_THROTTLE))
val rx = axis(dev, MotionEvent.AXIS_RX)
val hasRxRy = rx != null && has(MotionEvent.AXIS_RY)
// Whichever pair the fallback is about to pick, ask THAT one where it rests.
val restsNegative = if (buttons == PadButtons.GENERIC_SONY) {
(rx?.min ?: 0f) < -0.5f
} else {
(axis(dev, MotionEvent.AXIS_Z)?.min ?: 0f) < -0.5f
}
val map = padMap(buttons, namedTriggers = named, hasRxRy = hasRxRy, restsNegative = restsNegative)
padMaps[dev.descriptor] = map
return map
}
/**
* The axis half of [padMap], decided from four facts about the device so it can be pinned
* without one see `PadButtonsTest`. [namedTriggers] is whether the pad calls its triggers
* anything Android knows (LTRIGGER/RTRIGGER, BRAKE/GAS, BRAKE/THROTTLE); if it does, nothing
* here applies and the pad is read exactly as it always was. [restsNegative] is measured off
* whichever axis pair the fallback picks, never assumed.
*/
fun padMap(
buttons: PadButtons,
namedTriggers: Boolean,
hasRxRy: Boolean,
restsNegative: Boolean,
): PadMap = when {
namedTriggers || !hasRxRy -> PadMap(buttons)
// X, Y, Z, Rz, Rx, Ry = left stick, right stick, triggers. The sticks already read right.
buttons == PadButtons.GENERIC_SONY -> PadMap(
buttons,
leftTrigger = MotionEvent.AXIS_RX,
rightTrigger = MotionEvent.AXIS_RY,
triggersSigned = restsNegative,
)
// Right stick on Rx/Ry and triggers on Z/Rz — the shape in which reading Z/Rz as the
// right stick makes pulling a trigger swing it.
else -> PadMap(
buttons,
rightStickX = MotionEvent.AXIS_RX,
rightStickY = MotionEvent.AXIS_RY,
leftTrigger = MotionEvent.AXIS_Z,
rightTrigger = MotionEvent.AXIS_RZ,
triggersSigned = restsNegative,
)
}
/** [dev]'s range for one joystick [axis], under either source class a pad reports on. */
private fun axis(dev: InputDevice, axis: Int): InputDevice.MotionRange? =
dev.getMotionRange(axis, InputDevice.SOURCE_JOYSTICK)
?: dev.getMotionRange(axis, InputDevice.SOURCE_GAMEPAD)
/**
* The keycode [event] should have carried, given the controller it came from [event]'s own
* keycode for every pad Android has a key layout for, and the scancode's true button for one
* it does not (see the block comment above [PadButtons]).
*
* A drop-in for `event.keyCode` at every gamepad reader: the console UI's navigation, the
* Controllers screen's tester, and the streaming branch all route through it, so a mis-mapped
* pad is fixed in the menus and in the game at once. Events from anything that is not a
* controller, and events with no scancode (soft keyboards, synthetic events), pass through
* untouched.
*/
fun padKeyCode(event: KeyEvent): Int {
val dev = event.device ?: return event.keyCode
if (event.scanCode == 0 || !isPad(dev)) return event.keyCode
return padMap(dev).buttons.correct(event.scanCode, event.keyCode)
}
/**
* Maps one controller's joystick MotionEvents to axis (+ HATdpad) sends on wire pad index [pad],
* **on change only**. Holds the previous axis/hat state so an unchanged frame emits nothing. One
@@ -306,7 +608,12 @@ object Gamepad {
* node (DualSense/DS4 motion sensors), which reports every pad axis as 0. [onMotion] therefore
* folds the event straight in without re-qualifying it.
*/
class AxisMapper(private val handle: Long, private val pad: Int) {
class AxisMapper(
private val handle: Long,
private val pad: Int,
/** Which axes this controller's right stick and triggers arrive on — see [padMap]. */
private val map: PadMap = NATIVE_MAP,
) {
// Sentinel so the first real value (incl. 0) always sends once after attach (Linux parity).
private val last = IntArray(6) { Int.MIN_VALUE }
private var hatX = 0 // -1 / 0 / +1
@@ -317,30 +624,18 @@ object Gamepad {
// Sticks: Android floats 1..1, +y = down → ±32767, negate Y for the wire's +y = up.
sendAxis(AXIS_LS_X, stick(event.getAxisValue(MotionEvent.AXIS_X)))
sendAxis(AXIS_LS_Y, stick(-event.getAxisValue(MotionEvent.AXIS_Y)))
sendAxis(AXIS_RS_X, stick(event.getAxisValue(MotionEvent.AXIS_Z)))
sendAxis(AXIS_RS_Y, stick(-event.getAxisValue(MotionEvent.AXIS_RZ)))
sendAxis(AXIS_RS_X, stick(event.getAxisValue(map.rightStickX)))
sendAxis(AXIS_RS_Y, stick(-event.getAxisValue(map.rightStickY)))
// Triggers: pads report LTRIGGER/RTRIGGER or BRAKE/GAS (some mirror both) — merge
// with max, the same fold as the Controllers screen probe, so a pad that reports
// only one pair and a pad that reports both behave identically; 0..1 → 0..255.
sendAxis(
AXIS_LT,
trigger(
maxOf(
event.getAxisValue(MotionEvent.AXIS_LTRIGGER),
event.getAxisValue(MotionEvent.AXIS_BRAKE),
),
),
)
sendAxis(
AXIS_RT,
trigger(
maxOf(
event.getAxisValue(MotionEvent.AXIS_RTRIGGER),
event.getAxisValue(MotionEvent.AXIS_GAS),
),
),
)
// only one pair and a pad that reports both behave identically; 0..1 → 0..255. A pad
// reporting NONE of those names is one Android has no key layout for, and [map]
// carries the raw axes its triggers really landed on instead.
val lt = resolved(event, map.leftTrigger, MotionEvent.AXIS_LTRIGGER, MotionEvent.AXIS_BRAKE)
val rt = resolved(event, map.rightTrigger, MotionEvent.AXIS_RTRIGGER, MotionEvent.AXIS_GAS)
sendAxis(AXIS_LT, trigger(lt))
sendAxis(AXIS_RT, trigger(rt))
// HAT → dpad button transitions. Android BATCHES joystick ACTION_MOVEs, so a rapid d-pad
// tap (press+release inside one batch window) lives only in the historical samples — the
@@ -383,6 +678,17 @@ object Gamepad {
hatY = 0
}
/**
* One trigger's 0..1 value: [resolvedAxis] when this pad needed one resolved for it,
* else the max of the two names Android gives a trigger it does know.
*/
private fun resolved(event: MotionEvent, resolvedAxis: Int, named: Int, alias: Int): Float =
if (resolvedAxis == AXIS_NONE) {
maxOf(event.getAxisValue(named), event.getAxisValue(alias))
} else {
map.level(event.getAxisValue(resolvedAxis))
}
private fun sendAxis(id: Int, v: Int) {
if (last[id] == v) return
last[id] = v
@@ -605,7 +605,7 @@ class GamepadRouter(
// for the slot's life; the sensor path reads it on every sample.
val slot = Slot(
index,
Gamepad.AxisMapper(handle, index),
Gamepad.AxisMapper(handle, index, Gamepad.padMap(dev)),
NativeBridge.nativePadMotionReaches(handle, pref),
)
slots[dev.id] = slot
@@ -0,0 +1,203 @@
package io.unom.punktfunk.kit
import android.view.KeyEvent
import android.view.MotionEvent
import org.junit.Assert.assertEquals
import org.junit.Test
/**
* Pure JVM test of [Gamepad.PadButtons.correct] the scancode resolution for controllers Android
* has no key layout for. Only `KeyEvent`'s compile-time-inlined keycode constants are involved, so
* no Android runtime is needed. Run: `./gradlew :kit:testDebugUnitTest`.
*
* The regression it pins is a field report from a Fire TV Stick 4K Max (2026-08-20): a DualSense
* and an Xbox Elite Series 2, both over Bluetooth, both identified correctly but with buttons
* landing on the wrong actions "L1 being L2". Neither pad has a key layout on that box (AOSP
* ships none for `045e:0b05` at all, and the DualSense's requires `CONFIG_HID_PLAYSTATION`), so
* both fall back to `Generic.kl`, which names keycodes by scancode POSITION. A pad with no kernel
* driver numbers its HID buttons 1..n straight through in its own report order, so every keycode
* after the first divergence belongs to a different button.
*
* The table below is the pad's physical button on the left and where `Generic.kl` put it on the
* right; the assertions read it back the other way.
*/
class PadButtonsTest {
private fun sony(scan: Int) =
Gamepad.PadButtons.GENERIC_SONY.correct(scan, Gamepad.genericKeyCode(scan))
private fun xbox(scan: Int) =
Gamepad.PadButtons.GENERIC_XBOX.correct(scan, Gamepad.genericKeyCode(scan))
/**
* The exact report: a DualSense's L2 sits at scancode `0x136`, which `Generic.kl` calls
* BUTTON_L1 so pulling L2 read as a shoulder press, and L1 (at `0x134`, read as BUTTON_Y)
* read as a face button.
*/
@Test
fun `a DualSense's shoulders stop being each other's buttons`() {
assertEquals(KeyEvent.KEYCODE_BUTTON_L1, sony(0x134)) // L1, delivered as BUTTON_Y
assertEquals(KeyEvent.KEYCODE_BUTTON_R1, sony(0x135)) // R1, delivered as BUTTON_Z
assertEquals(KeyEvent.KEYCODE_BUTTON_L2, sony(0x136)) // L2, delivered as BUTTON_L1
assertEquals(KeyEvent.KEYCODE_BUTTON_R2, sony(0x137)) // R2, delivered as BUTTON_R1
}
/** ✕ is the bottom button — the one A means everywhere else — and □ is the left one. */
@Test
fun `a DualSense's face buttons land on their Xbox positions`() {
assertEquals(KeyEvent.KEYCODE_BUTTON_X, sony(0x130)) // □
assertEquals(KeyEvent.KEYCODE_BUTTON_A, sony(0x131)) // ✕
assertEquals(KeyEvent.KEYCODE_BUTTON_B, sony(0x132)) // ○
assertEquals(KeyEvent.KEYCODE_BUTTON_Y, sony(0x133)) // △
}
/**
* Create/Options/L3/R3/PS. Select in particular: without this it arrived as BUTTON_THUMBL,
* which took the exit, mic and stats chords with it every one of them is built on Select.
*/
@Test
fun `a DualSense's menu buttons and stick clicks are themselves`() {
assertEquals(KeyEvent.KEYCODE_BUTTON_SELECT, sony(0x138)) // Create
assertEquals(KeyEvent.KEYCODE_BUTTON_START, sony(0x139)) // Options
assertEquals(KeyEvent.KEYCODE_BUTTON_THUMBL, sony(0x13a)) // L3
assertEquals(KeyEvent.KEYCODE_BUTTON_THUMBR, sony(0x13b)) // R3
assertEquals(KeyEvent.KEYCODE_BUTTON_MODE, sony(0x13c)) // PS
}
/** The touchpad click and mute have no wire button; they must resolve to nothing, not to R3. */
@Test
fun `a DualSense's touchpad and mute are dropped rather than mistaken`() {
assertEquals(KeyEvent.KEYCODE_UNKNOWN, sony(0x13d))
assertEquals(KeyEvent.KEYCODE_UNKNOWN, sony(0x13e))
assertEquals(0, Gamepad.buttonBit(sony(0x13d)))
}
/** An Xbox-layout pad numbering straight through: A B X Y LB RB View Menu LS RS. */
@Test
fun `an Xbox pad numbering straight through keeps its own layout`() {
assertEquals(KeyEvent.KEYCODE_BUTTON_A, xbox(0x130))
assertEquals(KeyEvent.KEYCODE_BUTTON_B, xbox(0x131))
assertEquals(KeyEvent.KEYCODE_BUTTON_X, xbox(0x132))
assertEquals(KeyEvent.KEYCODE_BUTTON_Y, xbox(0x133))
assertEquals(KeyEvent.KEYCODE_BUTTON_L1, xbox(0x134))
assertEquals(KeyEvent.KEYCODE_BUTTON_R1, xbox(0x135))
assertEquals(KeyEvent.KEYCODE_BUTTON_SELECT, xbox(0x136)) // View
assertEquals(KeyEvent.KEYCODE_BUTTON_START, xbox(0x137)) // Menu
assertEquals(KeyEvent.KEYCODE_BUTTON_THUMBL, xbox(0x138))
assertEquals(KeyEvent.KEYCODE_BUTTON_THUMBR, xbox(0x139))
}
/** `hid-playstation` emits the modern Linux codes, where only the face pair reads swapped. */
@Test
fun `a driver-backed Sony pad has only its face pair corrected`() {
val m = Gamepad.PadButtons.SONY_MODERN
assertEquals(KeyEvent.KEYCODE_BUTTON_Y, m.correct(0x133, KeyEvent.KEYCODE_BUTTON_X)) // △
assertEquals(KeyEvent.KEYCODE_BUTTON_X, m.correct(0x134, KeyEvent.KEYCODE_BUTTON_Y)) // □
for (scan in listOf(0x130, 0x131, 0x136, 0x137, 0x13a, 0x13b, 0x13c)) {
assertEquals(Gamepad.genericKeyCode(scan), m.correct(scan, Gamepad.genericKeyCode(scan)))
}
}
/**
* The guard that makes all of this safe to run on every pad: a keycode that is NOT what
* `Generic.kl` would have said came from a device-specific key layout, which knows this
* controller better than any table here. Correcting it would break a pad that works.
*/
@Test
fun `a keycode a device layout already resolved is never second-guessed`() {
// AOSP's DualSense layout puts △ on BUTTON_Y itself. Every profile must leave it be.
for (p in Gamepad.PadButtons.entries) {
assertEquals(KeyEvent.KEYCODE_BUTTON_Y, p.correct(0x133, KeyEvent.KEYCODE_BUTTON_Y))
}
// Same for a scancode outside the generic gamepad block entirely — a pad's Back key.
assertEquals(
KeyEvent.KEYCODE_BACK,
Gamepad.PadButtons.GENERIC_SONY.correct(158, KeyEvent.KEYCODE_BACK),
)
}
/** Correcting twice is correcting once — the output is never itself a generic-layout answer. */
@Test
fun `correction is idempotent`() {
for (p in Gamepad.PadButtons.entries) {
for (scan in 0x130..0x13e) {
val once = p.correct(scan, Gamepad.genericKeyCode(scan))
assertEquals(once, p.correct(scan, once))
}
}
}
/**
* The axis half. A pad that names its triggers something Android knows is read exactly as it
* always was this is the branch that must NOT fire on the pads that already work.
*/
@Test
fun `a pad that names its triggers is read unchanged`() {
for (p in Gamepad.PadButtons.entries) {
val map = Gamepad.padMap(p, namedTriggers = true, hasRxRy = true, restsNegative = true)
assertEquals(MotionEvent.AXIS_Z, map.rightStickX)
assertEquals(MotionEvent.AXIS_RZ, map.rightStickY)
assertEquals(Gamepad.AXIS_NONE, map.leftTrigger)
assertEquals(Gamepad.AXIS_NONE, map.rightTrigger)
}
// Same when there is no Rx/Ry to fall back to in the first place.
val none = Gamepad.padMap(Gamepad.PadButtons.GENERIC_SONY, false, hasRxRy = false, restsNegative = false)
assertEquals(Gamepad.AXIS_NONE, none.leftTrigger)
}
/**
* A Sony pad reporting straight through lays out X, Y, Z, Rz, Rx, Ry left stick, right
* stick, then the triggers. Only the triggers were being missed; the sticks already read
* right and must be left alone.
*/
@Test
fun `an unmapped Sony pad keeps its sticks and gains its triggers`() {
val map = Gamepad.padMap(Gamepad.PadButtons.GENERIC_SONY, false, hasRxRy = true, restsNegative = false)
assertEquals(MotionEvent.AXIS_Z, map.rightStickX)
assertEquals(MotionEvent.AXIS_RZ, map.rightStickY)
assertEquals(MotionEvent.AXIS_RX, map.leftTrigger)
assertEquals(MotionEvent.AXIS_RY, map.rightTrigger)
}
/**
* Every other unmapped pad is the opposite way round: right stick on Rx/Ry, triggers on Z/Rz.
* Reading Z/Rz as the right stick there is what makes pulling a trigger swing it so the two
* pairs must never be mixed up, which is the whole point of pinning them.
*/
@Test
fun `an unmapped Xbox-layout pad has its stick and triggers the other way round`() {
for (p in listOf(Gamepad.PadButtons.GENERIC_XBOX, Gamepad.PadButtons.SONY_MODERN)) {
val map = Gamepad.padMap(p, namedTriggers = false, hasRxRy = true, restsNegative = false)
assertEquals(MotionEvent.AXIS_RX, map.rightStickX)
assertEquals(MotionEvent.AXIS_RY, map.rightStickY)
assertEquals(MotionEvent.AXIS_Z, map.leftTrigger)
assertEquals(MotionEvent.AXIS_RZ, map.rightTrigger)
}
}
/**
* A trigger axis that idles at 1 is rescaled; one that idles at 0 must NOT be, or it would
* read as a permanent half-pull. Which it is gets measured off the device, never assumed
* both the DualSense's raw RX/RY and the Xbox pad's Z/Rz report an honest 0..1.
*/
@Test
fun `only a trigger that idles negative is rescaled`() {
val signed = Gamepad.padMap(Gamepad.PadButtons.GENERIC_SONY, false, hasRxRy = true, restsNegative = true)
assertEquals(0f, signed.level(-1f), 1e-6f)
assertEquals(0.5f, signed.level(0f), 1e-6f)
assertEquals(1f, signed.level(1f), 1e-6f)
val unsigned = Gamepad.padMap(Gamepad.PadButtons.GENERIC_SONY, false, hasRxRy = true, restsNegative = false)
assertEquals(0f, unsigned.level(0f), 1e-6f)
assertEquals(1f, unsigned.level(1f), 1e-6f)
}
/** A pad Android does know is untouched, which is most of them. */
@Test
fun `a pad with a key layout is left alone`() {
for (scan in 0x130..0x13e) {
val generic = Gamepad.genericKeyCode(scan)
assertEquals(generic, Gamepad.PadButtons.NATIVE.correct(scan, generic))
}
}
}
@@ -30,7 +30,7 @@
use super::{AppState, CONTROL_PORT};
use crate::inject::gamepad::GamepadManager;
use anyhow::{anyhow, Context, Result};
use punktfunk_core::input::InputEvent;
use punktfunk_core::input::{GamepadEvent, InputEvent};
use punktfunk_core::quic::{classify, GrantClass, HdrMeta, GRANT_ALL};
use rusty_enet::{Event, Host, HostSettings, Packet, PeerID};
use std::net::UdpSocket;
@@ -229,6 +229,65 @@ fn permitted(mask: u32, class: GrantClass, drops: &mut GrantDrops) -> bool {
false
}
/// The virtual Xbox pad a Moonlight session presents, and the one place this plane decides which
/// backend builds it.
///
/// On Windows there are two, and they are not interchangeable to a game: the XUSB companion
/// registers only `GUID_DEVINTERFACE_XUSB` and exposes no HID collection, so Steam's hidapi
/// enumeration, SDL, RawInput, DirectInput, `joy.cpl` and WGI/GameInput cannot see it at all —
/// only classic `XInputGetState` can. The native plane made the HID pad its default on
/// 2026-08-09 for exactly that reason; this plane kept constructing
/// [`GamepadManager`](crate::inject::gamepad::GamepadManager) directly and so kept handing
/// Moonlight clients a pad most games cannot enumerate. Both planes now read the same knob —
/// `native::gamepad::windows_xbox_hid` (not an intra-doc link: it is `cfg(windows)`, so the link
/// would not resolve on any other target) — so `PUNKTFUNK_XBOX_BACKEND=xusb` reverts both
/// together and neither can drift again.
///
/// Everywhere else the choice does not exist: Linux has one uinput X-Box pad, and the stub
/// backend on other platforms drops events.
enum SessionPads {
/// Linux uinput / the Windows XUSB companion — `crate::inject::gamepad`.
Xusb(GamepadManager),
/// The Windows UMDF HID Xbox pad, what the native plane builds by default.
#[cfg(target_os = "windows")]
Hid(crate::inject::xbox_windows::XboxWindowsManager),
}
impl SessionPads {
/// Build this session's pad manager, honoring the shared Windows backend knob.
fn new() -> SessionPads {
#[cfg(target_os = "windows")]
if crate::native::gamepad::windows_xbox_hid() {
return SessionPads::Hid(crate::inject::xbox_windows::XboxWindowsManager::new());
}
SessionPads::Xusb(GamepadManager::new())
}
/// Apply one decoded controller event (create/destroy by mask, then state).
fn handle(&mut self, ev: &GamepadEvent) {
match self {
SessionPads::Xusb(m) => m.handle(ev),
#[cfg(target_os = "windows")]
SessionPads::Hid(m) => m.handle(ev),
}
}
/// Service the pads' feedback protocol and relay changed rumble levels. Games block inside the
/// kernel/driver handshake until answered, so call this every tick.
///
/// The HID pad's rich-feedback plane is discarded rather than plumbed: an Xbox pad has no
/// lightbar or adaptive triggers to report, and GameStream has no vocabulary for one either —
/// its rumble message (`0x010B`, [`super::gamepad::rumble_plaintext`]) carries the two handle
/// motors and nothing else, which is also why the trigger levels are dropped at the call site.
fn pump_rumble(&mut self, rumble: impl FnMut(u16, u16, u16, u16, u16)) {
match self {
SessionPads::Xusb(m) => m.pump_rumble(rumble),
#[cfg(target_os = "windows")]
SessionPads::Hid(m) => m.pump(rumble, |_| {}),
}
}
}
/// Reconcile the control port to the paired-client list: bound while at least one pairing
/// exists, closed when none remain. Idempotent and race-free (see [`Gate::running`]); call it
/// wherever the paired list changes — startup, pairing phase 4, unpair.
@@ -362,7 +421,7 @@ fn spawn(state: Arc<AppState>) -> Result<Running> {
// by every outbound message (rumble + the HDR-mode signal): the GCM nonce is derived
// from `seq`, so a per-message-type counter would reuse (key, nonce) pairs across
// message types in the host direction.
let mut pads = GamepadManager::new();
let mut pads = SessionPads::new();
// Pen/touch translator (SS_PEN/SS_TOUCH → virtual tablet / wire touch). Sent only
// by clients that saw our SS_FF_PEN_TOUCH_EVENTS feature flag (rtsp.rs).
let mut pointer = super::pen::GsPointer::new();
@@ -480,7 +539,7 @@ fn spawn(state: Arc<AppState>) -> Result<Running> {
hdr_sent = false;
// Unplug the session's virtual pads + tablet (destroying the
// uinput pen releases any held tool/tip kernel-side).
pads = GamepadManager::new();
pads = SessionPads::new();
pointer = super::pen::GsPointer::new();
// Surface the session's enforcement-drop totals (WP13).
drops.end_of_session();
@@ -583,7 +642,7 @@ fn spawn(state: Arc<AppState>) -> Result<Running> {
detected = None;
decrypt_fails = 0;
hdr_sent = false;
pads = GamepadManager::new();
pads = SessionPads::new();
pointer = super::pen::GsPointer::new();
drops.end_of_session();
}
@@ -689,7 +748,7 @@ fn on_receive(
detected: &mut Option<Scheme>,
decrypt_fails: &mut u64,
inj_tx: &Sender<InputEvent>,
pads: &mut GamepadManager,
pads: &mut SessionPads,
pointer: &mut super::pen::GsPointer,
grants: u32,
drops: &mut GrantDrops,
+4 -2
View File
@@ -48,8 +48,10 @@ mod compositor;
use compositor::resolve_compositor;
/// Virtual-gamepad backend resolution (plan §W1); `serve_session` + the `Pads` state machine reach
/// `resolve_gamepad`/`resolve_pad_kind`/`route_decision` here.
mod gamepad;
/// `resolve_gamepad`/`resolve_pad_kind`/`route_decision` here. Crate-visible because the choice of
/// Windows Xbox backend (`windows_xbox_hid`) is not the native plane's alone — the GameStream plane
/// presents the same virtual pad and has to make the same choice, from one definition.
pub(crate) mod gamepad;
use gamepad::{resolve_gamepad, resolve_pad_kind, route_decision};
/// The SPAKE2 pairing ceremony (plan §W1); `serve_session` dispatches a PairRequest connection here.
+6 -1
View File
@@ -363,8 +363,13 @@ fn degrade_xbox_identity(chosen: GamepadPref) -> GamepadPref {
///
/// The two backends are mutually exclusive per pad by construction (one match arm or the other) —
/// presenting both would hand a game two controllers for one pair of hands.
///
/// Read by BOTH input planes. The native plane branches on it in `Pads::handle`; the GameStream
/// plane in `gamestream::control::SessionPads`. It was `pub(super)` while only the native plane
/// consulted it, and that is exactly how Moonlight sessions spent two releases on the XUSB pad
/// after this default flipped — the knob was unreachable from the module that needed it.
#[cfg(target_os = "windows")]
pub(super) fn windows_xbox_hid() -> bool {
pub(crate) fn windows_xbox_hid() -> bool {
match std::env::var("PUNKTFUNK_XBOX_BACKEND") {
Ok(v) if v.trim().eq_ignore_ascii_case("xusb") => false,
// Anything else — unset, empty, "hid", or a typo — takes the default. A misspelled opt-out