Legion Go S: built-in controller always duplicates external controller's rumble, and stops responding to input depending on launch order

[Labaman]

Two consistent, reproducible behaviors when an external controller is connected alongside the built-in one:

1. Rumble: the built-in controller always rumbles at the same time as the external controller, for the same in-game event — every time, not intermittently.
2. Input: whether the built-in controller responds to its own buttons/sticks depends on which controller was active when the game was launched (see below).

Environment

• Device: Lenovo Legion Go S 8APU1
• OS: Bazzite 44.20260908 (bazzite-deck:stable)
• Kernel: 7.2.3-ogc3.1.fc44.x86_64
• InputPlumber: 0.79.0-4.fc44
• Steam client manifest version: 1788652215
• External controllers tested: 8BitDo Ultimate 2 Wireless (Bluetooth) and a Sony DualSense — same results with both, so this doesn't seem tied to a specific external controller.
• Game tested: Diablo II Resurrected. I ran the full sequence twice — once in Desktop Mode, once in Gamescope Game Mode (separate boot) — same results in both.
• No custom configuration involved (default InputPlumber setup).

It also reproduced on the same device using:

• OS: SteamOS 3.8.16 Stable
• Kernel: 6.16.12-valve24.5-1-neptune-616-gb2f7cfe85e45
• InputPlumber: 0.77.4
• Steam client manifest version: 1788652215

Steps to reproduce and observed results

A. Launch with the external controller, then try the built-in one mid-session:

1. Quit the game completely.
2. With the external controller already connected, launch the game and go through all menus using only the external controller.
3. During gameplay, press buttons / move sticks on the built-in controller.
4. Result: no reaction at all from the built-in controller for the rest of the session — as if it isn't connected.

B. Launch with the built-in controller, then connect the external one mid-session:

1. Launch the game, play using only the built-in controller (input and rumble both work normally).
2. While still in-game, connect the external controller.
3. Result: both controllers now respond to input correctly. However, rumble on the external controller stops working — only the built-in controller rumbles from that point on.

Additional check

To rule out a hardware/driver problem, I drove the built-in controller's rumble motor directly via InputPlumber, bypassing Steam entirely:

busctl --system call org.shadowblip.InputPlumber \
  /org/shadowblip/InputPlumber/CompositeDevice0 \
  org.shadowblip.Output.ForceFeedback Rumble d 1.0

This reliably produces physical vibration in every state described above, including when the built-in controller is otherwise completely unresponsive (scenario A). I also tried systemctl restart inputplumber while the built-in controller was unresponsive; it did not restore it inside the already-running game — restarting the game itself was needed.

Partial workaround

Disabling the built-in controller's rumble output before launching mitigates the duplicate-rumble part only:

busctl --system set-property org.shadowblip.InputPlumber \
  /org/shadowblip/InputPlumber/CompositeDevice0 \
  org.shadowblip.Output.ForceFeedback Enabled b false

With this set beforehand, playing a whole session with only the external controller (scenario A) works fine — no rumble duplication, external rumble is normal. It does not fix the built-in controller staying unresponsive to input in that same scenario.

Comparison (not controlled — differs in several variables)

I ran the same steps on Steam Deck, SteamOS 3.8.16 (Stable), with a DualSense as the external controller, and did not see either behavior — switching worked correctly in both directions and only the actively-used controller rumbled. This differs in hardware, and possibly in Steam client build, so I'm reporting it only as a data point, not as a conclusion about where the problem lies.

[Labaman]

A quick update:

I ran a few more tests and got the following results:

• In games with native SteamInput support (e.g. Horizon Zero Dawn Remastered), none of the described issues occur — vibration isn’t duplicated, and switching controllers “on the fly” also works correctly — only the controller in use vibrates
• In some “older” games, such as Darksiders: Warmastered Edition, an “exacerbated” version of scenario B occurs: the game only recognizes the controller that was active at the exact moment it was launched — switching “on the fly” does not occur, whether from the built-in controller to an external one or vice versa. A controller that is inactive at the moment the game launches does not replicate vibration and does not respond to input during the gameplay session.

[Labaman]

Found one more detail:
Restarting inputplumber.service (e.g. via Desktop Mode) causes the built-in controller to get mislabeled as an Xbox Elite pad

Before restart, built-in composite device (PersistentId wch.cn_Legion_Go_S_*) is bound to deck-uhid:

  DeviceType: "deck-uhid"
  Name: "Valve Steam Deck Controller"

After restarting inputplumber with an external controller connected, same composite device (still correctly identified via PersistentId/SourceDevicePaths as the built-in) gets rebound instead to:

  DeviceType: "xbox-elite"
  Name: "Microsoft X-Box One Elite pad"

This sticks around on subsequent restarts even with a completely different (or no) external controller connected.

So the built-in controller can end up permanently misidentified as an Xbox Elite pad (wrong buttons/paddles/capabilities) after a restart, regardless of what's actually connected afterward. Possibly same root cause as the rumble/input issues above.