[Legion Go S] SIPO touchpad behaves erratically when handled by InputPlumber, works when inputplumber.service is stopped

[jpvalencia1289]

Summary

The built-in touchpad behaves erratically on a Lenovo Legion Go S running factory SteamOS.

The hardware itself appears to work: when inputplumber.service is stopped, the physical mouse/touchpad path works as a normal pointer. The problem appears when InputPlumber claims/blocks the physical wch.cn Legion Go S Mouse and wch.cn Legion Go S Touchpad devices and routes them through the virtual target.

Device

• Device: Lenovo Legion Go S
• APU: AMD Ryzen Z1 Extreme
• RAM/storage: 32 GB / 1 TB
• OS: factory SteamOS
• Touchpad: SIPO
• Touchpad firmware: v21
• InputPlumber version: 0.77.2
• Package: inputplumber 0.77.2-2

Current input device mapping

On my system, the relevant devices currently appear as:

/dev/input/event3 -> wch.cn Legion Go S Mouse
/dev/input/event4 -> wch.cn Legion Go S Keyboard
/dev/input/event5 -> wch.cn Legion Go S UNKNOWN
/dev/input/event6 -> wch.cn Legion Go S Touchpad
/dev/input/event8 -> Legion Go S

/dev/input/by-id includes:

usb-wch.cn_Legion_Go_S_-event-if02 -> ../event5
usb-wch.cn_Legion_Go_S_-if01-event-joystick -> ../event8
usb-wch.cn_Legion_Go_S_-if01-joystick -> ../js0
usb-wch.cn_Legion_Go_S_-if02-event-mouse -> ../event3
usb-wch.cn_Legion_Go_S_-if02-mouse -> ../mouse0

What happens

InputPlumber detects the Legion Go S profile and creates the composite device, but then blocks the physical mouse/touchpad evdev devices:

Blocking input events from /dev/input/event6
Blocking input events from /dev/input/event3

The output capabilities include trackpad haptics:

Output capabilities changed: {ForceFeedbackUpload, Haptics(TrackpadLeft), Haptics(TrackpadRight), LED(Brightness), ForceFeedbackErase, LED(Color), ForceFeedback}

After this, the built-in touchpad behavior is unreliable/erratic in SteamOS / Steam Input. In Desktop Mode it appears to function correctly, in Gaming Mode the behaviour is erratical, random detection, stops working after suspension or reset.

Expected behavior

The built-in SIPO touchpad should consistently work as a Steam Input / Steam Deck-style trackpad after boot and resume.

Important observation

If I stop InputPlumber:

sudo systemctl stop inputplumber.service

the physical touchpad/mouse path works as a normal pointer.

This suggests the hardware and libinput side are functional. The problem appears to be in the InputPlumber handling/translation path for the Legion Go S wch.cn mouse/touchpad devices.

Additional context

This may be related to the same general class of issue as #584 / #602, although my issue is not specifically the Legion Go 2 mouse wheel issue. In my case, the physical mouse/touchpad devices are detected and then blocked by InputPlumber, but the virtual output path does not behave reliably.

Attached logs

I attached a tarball containing:

• system-info.txt
• pacman-Qkk-inputplumber.txt
• inputplumber-status.txt
• inputplumber-systemd-unit.txt
• inputplumber-journal-current-boot.txt
• input-devices.txt
• udevadm-*
• dmesg-filtered-input.txt
• inputplumber-devices.txt
• inputplumber-device0-info.txt
• 50-legion_go_s.yaml
• InputPlumber udev/hwdb/dbus/polkit files

I can run extra commands or test a branch/build on the Legion Go S if needed.

legion-go-s-inputplumber-issue-20260610-095306.tar.gz

[pastaq]

This isn't an InputPlumber issue, it's actually two separate issues. The first is asteam client issue on how it's handling the hid reports from the virtual deck controller while in game mode. The second is a firmware issue specific to the SIPO touchpad.

In Desktop Mode it appears to function correctly

If InputPlumber were the issue then this wouldn't be the case. InputPlumber is still doing a 1:1 translation from the go S hid report to the deck hid report in desktop mode, the only difference is how steam reads the input in those modes. InputPlumber is not context aware of how it's virtual device is being managed, so it cannot adjust behavior based on the session or environment unless told to by a userspace application.

You can test InputPlumber touch detection with inputplumber device 0 test while in gamemode to verify.

stops working after suspension or reset.

This doesn't affect the BetterLife version of the touchpad. The SIPO touchpad doesn't appear to accept the udev rules for mode switching during those events. Lenovo or SIPO need to fix this in firmware.

There is one additional thing I was planning on attempting in the Go S kernel drivers as a potential workaround, which would be to refactor the device init so the attributes only appear after the probe scheduled work queue has finished, as well as sending a kernel udev event for "change" after it's ready.

As a mitigation for this part of the issue you can manually set the windows mode from relative to absolute, then the mode switch won't matter as it will always be in absolute.

the behaviour is erratical, random detection,

I don't know what you mean by erratical. The "random detection" may just be a misunderstanding of how to activate the touchpad in different gamemode scenarios. In the steam UI/overlay you need to hold the guide button for steam to interpret the touchpad as a mouse input. This isn't the most intuitive behavior, I'll grant you that, but we have no control over how Valve implements Steam.

[jpvalencia1289]

Thanks for the quick and detailed reply, that explanation makes sense.

I did some more testing and you're right: the main issue on my unit seems to be the SIPO suspend/resume behavior you described.

A few updates from my side:

• I installed the latest SteamOS Beta/Preview update today, so that may also have changed the behavior somewhat.

• Cold boots are now working consistently for me.

• The problem was much more reproducible after suspending/resuming with the power button.

• I found the SIPO mode attributes under /sys/devices/.../0003:1A86:E310.0003/:

  • os_mode
  • touchpad/windows_mode
  • touchpad/linux_mode

Before applying any workaround I saw states such as:

os_mode=windows
windows_mode=relative
linux_mode=relative

or similar inconsistent states after resume.

As a local workaround, I made a small systemd/system-sleep script that forces:

os_mode=linux
windows_mode=absolute
linux_mode=absolute

after boot and after resume.

So far, with that mitigation, the touchpad is working correctly after cold boot and after suspend/resume.

Thanks again for pointing me in the right direction. This seems consistent with your explanation that the SIPO touchpad is not reliably handling the mode switch after suspend/resume.

Feel free to close this if you consider it outside the scope of InputPlumber.

[pastaq]

I'll leave it open for now so that it is searchable for others having similar issues. Would you mind posting your script so users who make it here with the same issue can at least get a workaround installed?

[jpvalencia1289]

Sure. Here is the local workaround I am currently using.

Small note: this was drafted with AI assistance and then tested locally on my own Legion Go S. I am not submitting it as a patch/PR, just sharing it here as a workaround for other users who may hit the same SIPO touchpad suspend/resume issue.

It forces the SIPO touchpad into absolute mode at boot and again after resume.

1. Create the fix script

sudo tee /etc/legion-sipo-touchpad-fix.sh >/dev/null <<'EOF'
#!/usr/bin/env bash

# Lenovo Legion Go S SIPO touchpad workaround.
# Force touchpad to absolute mode after boot/resume.

BASE=""

for i in {1..30}; do
  BASE="$(find /sys/devices -type f -name os_mode 2>/dev/null | grep -i '1a86:e310' | sed 's#/os_mode##' | head -n1)"
  [ -n "$BASE" ] && break
  sleep 0.5
done

[ -z "$BASE" ] && {
  logger -t legion-sipo-touchpad-fix "SIPO touchpad 1A86:E310 not found"
  exit 0
}

OS="$BASE/os_mode"
WIN="$BASE/touchpad/windows_mode"
LIN="$BASE/touchpad/linux_mode"

[ -w "$WIN" ] && echo absolute > "$WIN"
[ -w "$LIN" ] && echo absolute > "$LIN"
[ -w "$OS" ] && echo linux > "$OS"
[ -w "$WIN" ] && echo absolute > "$WIN"
[ -w "$LIN" ] && echo absolute > "$LIN"

logger -t legion-sipo-touchpad-fix "Applied SIPO touchpad fix: os_mode=$(cat "$OS" 2>/dev/null), windows_mode=$(cat "$WIN" 2>/dev/null), linux_mode=$(cat "$LIN" 2>/dev/null)"

exit 0
EOF

sudo chmod 755 /etc/legion-sipo-touchpad-fix.sh

2. Run it once manually

sudo /etc/legion-sipo-touchpad-fix.sh

You can check the current values with:

BASE="$(find /sys/devices -type f -name os_mode 2>/dev/null | grep -i '1a86:e310' | sed 's#/os_mode##' | head -n1)"
echo "OS  -> $(cat "$BASE/os_mode")"
echo "WIN -> $(cat "$BASE/touchpad/windows_mode")"
echo "LIN -> $(cat "$BASE/touchpad/linux_mode")"

Expected result:

OS  -> linux
WIN -> absolute
LIN -> absolute

3. Apply it automatically at boot

sudo tee /etc/systemd/system/legion-sipo-touchpad-fix.service >/dev/null <<'EOF'
[Unit]
Description=Force Lenovo Legion Go S SIPO touchpad absolute mode
After=inputplumber.service multi-user.target
Wants=inputplumber.service

[Service]
Type=oneshot
ExecStart=/etc/legion-sipo-touchpad-fix.sh

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now legion-sipo-touchpad-fix.service

4. Apply it again after suspend/resume

sudo mkdir -p /etc/systemd/system-sleep

sudo tee /etc/systemd/system-sleep/99-legion-sipo-touchpad-fix >/dev/null <<'EOF'
#!/bin/sh

case "$1/$2" in
  post/*)
    /etc/legion-sipo-touchpad-fix.sh
    ;;
esac
EOF

sudo chmod 755 /etc/systemd/system-sleep/99-legion-sipo-touchpad-fix

5. Check logs

journalctl -t legion-sipo-touchpad-fix -n 20 --no-pager

Rollback

sudo systemctl disable --now legion-sipo-touchpad-fix.service
sudo rm -f /etc/systemd/system/legion-sipo-touchpad-fix.service
sudo rm -f /etc/systemd/system-sleep/99-legion-sipo-touchpad-fix
sudo rm -f /etc/legion-sipo-touchpad-fix.sh
sudo systemctl daemon-reload

So far this has kept my SIPO touchpad working correctly after cold boot and after suspend/resume.