[PR #442] [MERGED] feat: better control over motion joypads #470

New issue

Closed

opened 2026-10-15 13:00:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:49 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/442
Author: @kmreisi
Created: 6/22/2026
Status: ✅ Merged
Merged: 6/23/2026
Merged by: @ABeltramo

Base: stable ← Head: fix/upgrade-unknown-with-gyro-to-ps

📝 Commits (3)

4ebbd98 feat: auto-promote UNKNOWN-with-motion clients to PS + motion_controller_override
39a317f lint: clang-format
3ab6360 fix: updated failing test

📊 Changes

6 files changed (+86 additions, -15 deletions)

View changed files

📝 docs/modules/user/pages/configuration.adoc (+31 -0)
📝 src/moonlight-server/api/api.hpp (+1 -0)
📝 src/moonlight-server/api/endpoints.cpp (+5 -1)
📝 src/moonlight-server/control/input_handler.cpp (+37 -13)
📝 src/moonlight-server/state/serialised_config.hpp (+10 -0)
📝 tests/testWolfAPI.cpp (+2 -1)

📄 Description

Problem

Wolf trusts the controller type the Moonlight client reports. For phone clients that's often wrong: moonlight-common-c (used by all Moonlight clients) advertises GYRO/ACCELEROMETER capability whenever the phone has sensors enabled, but Moonlight Android specifically downgrades the reported type to UNKNOWN whenever the phone has sensors and the underlying pad isn't already a DualSense:

// moonlight-android/app/src/main/java/com/limelight/binding/input/ControllerHandler.java#L3148
if (type != MoonBridge.LI_CTYPE_PS && sensorManager != null) {
    // Override the detected controller type if we're emulating motion sensors
    reportedType = MoonBridge.LI_CTYPE_UNKNOWN;
}

Wolf's default for UNKNOWN is the Xbox virtual pad. The motion-request blocks (if (capabilities & GYRO|ACCELEROMETER && final_type == PS)) only fire for PS pads — so the gyro/accel data the client is ready to send is silently dropped.

Fix

Two related changes, bundled:

1. Auto-detect (always on, no config)

When the client reports controller_type=UNKNOWN AND advertises GYRO or ACCELEROMETER, Wolf creates a PS5/DualSense pad instead of falling through to Xbox. The motion blocks then fire and the gyro data is forwarded end-to-end. Stock Moonlight Android with any non-PS pad on any phone with sensors enabled now gets motion routed out of the box.

The promotion is unconditional because Moonlight Android itself shows an in-game toast ("Gamepad type may be changed due to motion sensor emulation") when the user enables motion — the client-side already signals the type change is expected.

2. Per-client `motion_controller_override` setting

A new optional motion_controller_override: ControllerType field on ClientSettings (default AUTO). Sibling of controllers_override: same shape of "operator wants type X" but gated on the client actually having motion to forward. When controllers_override[slot] is unset, the client advertises GYRO/ACCELEROMETER, AND motion_controller_override != AUTO, Wolf forces that pad type instead of the auto-detected one.

PATCH /api/v1/clients/<id>/settings  { "motion_controller_override": "PS" }

Same plumbing as controllers_override — added to PartialClientSettings, threaded through both the lobby-create and client-settings-update endpoints.

Useful for "every motion-capable connection from this client should land on device X" preferences. Forward-compatible with PR #385's Switch Pro work — once those motion-gates extend beyond PS, motion_controller_override = "NINTENDO" will route motion to a Switch Pro pad.

Precedence

controllers_override[slot]   (per-slot)    ← highest, wins everything
        ↓ unset
motion_controller_override   (per-client)  ← forces type if motion advertised AND != AUTO
        ↓ AUTO
auto-detection                              ← UNKNOWN+motion → PS, else honour client's reported type

Compatibility

Existing clients with motion_controller_override unset keep their behaviour for explicit XBOX/PS/NINTENDO. The only behaviour change is for UNKNOWN-with-motion clients, which previously got Xbox+no-motion and now get DualSense+motion — universally an improvement for the affected users (everyone on Moonlight Android with a non-DS pad + sensors enabled).

Documented

In docs/modules/user/pages/configuration.adoc under "Override the default joypad mapping" — two new sub-sections covering the auto-detection and motion_controller_override.

Verified

End-to-end on a Pixel 7 running stock Moonlight Android with an Xbox pad attached: client reports UNKNOWN with GYRO|ACCELEROMETER, Wolf creates a DualSense, and gyro/accel events arrive at the virtual pad — no config needed. With motion_controller_override="XBOX" set on the same client, Wolf creates an Xbox pad instead.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/442 **Author:** [@kmreisi](https://github.com/kmreisi) **Created:** 6/22/2026 **Status:** ✅ Merged **Merged:** 6/23/2026 **Merged by:** [@ABeltramo](https://github.com/ABeltramo) **Base:** `stable` ← **Head:** `fix/upgrade-unknown-with-gyro-to-ps` --- ### 📝 Commits (3) - [`4ebbd98`](https://github.com/games-on-whales/wolf/commit/4ebbd98f654edabdabe35abdde633d7fdf2d61d8) feat: auto-promote UNKNOWN-with-motion clients to PS + motion_controller_override - [`39a317f`](https://github.com/games-on-whales/wolf/commit/39a317f223e1e595a552838808041bf85ac0b499) lint: clang-format - [`3ab6360`](https://github.com/games-on-whales/wolf/commit/3ab6360da5d93d31994eea7fd85f173b903f56dd) fix: updated failing test ### 📊 Changes **6 files changed** (+86 additions, -15 deletions) <details> <summary>View changed files</summary> 📝 `docs/modules/user/pages/configuration.adoc` (+31 -0) 📝 `src/moonlight-server/api/api.hpp` (+1 -0) 📝 `src/moonlight-server/api/endpoints.cpp` (+5 -1) 📝 `src/moonlight-server/control/input_handler.cpp` (+37 -13) 📝 `src/moonlight-server/state/serialised_config.hpp` (+10 -0) 📝 `tests/testWolfAPI.cpp` (+2 -1) </details> ### 📄 Description ## Problem Wolf trusts the controller type the Moonlight client reports. For phone clients that's often wrong: `moonlight-common-c` (used by all Moonlight clients) advertises `GYRO`/`ACCELEROMETER` capability whenever the phone has sensors enabled, but Moonlight Android specifically downgrades the **reported type** to `UNKNOWN` whenever the phone has sensors and the underlying pad isn't already a DualSense: ```java // moonlight-android/app/src/main/java/com/limelight/binding/input/ControllerHandler.java#L3148 if (type != MoonBridge.LI_CTYPE_PS && sensorManager != null) { // Override the detected controller type if we're emulating motion sensors reportedType = MoonBridge.LI_CTYPE_UNKNOWN; } ``` Wolf's default for UNKNOWN is the Xbox virtual pad. The motion-request blocks (`if (capabilities & GYRO|ACCELEROMETER && final_type == PS)`) only fire for PS pads — so the gyro/accel data the client is ready to send is silently dropped. ## Fix Two related changes, bundled: ### 1. Auto-detect (always on, no config) When the client reports `controller_type=UNKNOWN` AND advertises `GYRO` or `ACCELEROMETER`, Wolf creates a PS5/DualSense pad instead of falling through to Xbox. The motion blocks then fire and the gyro data is forwarded end-to-end. Stock Moonlight Android with any non-PS pad on any phone with sensors enabled now gets motion routed out of the box. The promotion is unconditional because Moonlight Android itself shows an in-game toast ("Gamepad type may be changed due to motion sensor emulation") when the user enables motion — the client-side already signals the type change is expected. ### 2. Per-client `motion_controller_override` setting A new optional `motion_controller_override: ControllerType` field on `ClientSettings` (default `AUTO`). Sibling of `controllers_override`: same shape of "operator wants type X" but gated on the client actually having motion to forward. When `controllers_override[slot]` is unset, the client advertises `GYRO`/`ACCELEROMETER`, AND `motion_controller_override != AUTO`, Wolf forces that pad type instead of the auto-detected one. ``` PATCH /api/v1/clients/<id>/settings { "motion_controller_override": "PS" } ``` Same plumbing as `controllers_override` — added to `PartialClientSettings`, threaded through both the lobby-create and client-settings-update endpoints. Useful for "every motion-capable connection from this client should land on device X" preferences. Forward-compatible with PR #385's Switch Pro work — once those motion-gates extend beyond `PS`, `motion_controller_override = "NINTENDO"` will route motion to a Switch Pro pad. ## Precedence ``` controllers_override[slot] (per-slot) ← highest, wins everything ↓ unset motion_controller_override (per-client) ← forces type if motion advertised AND != AUTO ↓ AUTO auto-detection ← UNKNOWN+motion → PS, else honour client's reported type ``` ## Compatibility Existing clients with `motion_controller_override` unset keep their behaviour for explicit XBOX/PS/NINTENDO. The only behaviour change is for UNKNOWN-with-motion clients, which previously got Xbox+no-motion and now get DualSense+motion — universally an improvement for the affected users (everyone on Moonlight Android with a non-DS pad + sensors enabled). ## Documented In `docs/modules/user/pages/configuration.adoc` under "Override the default joypad mapping" — two new sub-sections covering the auto-detection and `motion_controller_override`. ## Verified End-to-end on a Pixel 7 running stock Moonlight Android with an Xbox pad attached: client reports UNKNOWN with `GYRO|ACCELEROMETER`, Wolf creates a DualSense, and gyro/accel events arrive at the virtual pad — no config needed. With `motion_controller_override="XBOX"` set on the same client, Wolf creates an Xbox pad instead. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 13:00:49 +00:00