Environment
- InputPlumber 0.78.1 (CachyOS package
inputplumber 0.78.1-1.1)
- Lenovo Legion Go 2 (DMI
83N0), composite device from 50-legion_go_2.yaml
- Capabilities include
Touchpad:RightPad:Touch:Motion, Touchpad:RightPad:Touch:Button:{Touch,Press}
What I tried
A device profile that routes the physical trackpad to a plain mouse pointer, keeping it out of the deck-uhid emulation (use case below):
- name: Trackpad to mouse
source_event:
touchpad:
name: RightPad
touch:
motion: {}
target_events:
- mouse:
motion: {}
- name: Trackpad click to left click
source_event:
touchpad:
name: RightPad
touch:
button: Press
target_events:
- mouse:
button: LeftThe schema (device_profile_v1.json) accepts both mappings.
What happens
Both translations are unimplemented at runtime, so the events are swallowed (trackpad goes completely dead) with one warning per event:
WARN inputplumber::input::composite_device] Translation not implemented for profile mapping 'Trackpad to mouse': Touchpad(RightPad(Motion)) -> Mouse(Motion)
Looking at src/input/event/value.rs (the // TODO: Implement all possible translations block):
Touchpad … Touch::Motion → Mouse::Motion is an explicit TranslationError::NotImplemented (marked // TODO:).Touch::Button(_) as a source returns NotImplemented for every target, so touchpad button events cannot be remapped to anything at all.
Why it matters (use case)
On desktop sessions, Steam hijacks any emulated trackpad (Deck and DualSense targets both) into its on-screen-keyboard typing mode whenever the OSK opens. The only clean way out is to keep the physical trackpad out of the gamepad emulation entirely and deliver it as a plain pointer — exactly what the mapping above expresses.
Partial workaround I found: remap RightPad → CenterPad motion (implemented, plain clone) with the touchpad target added — deck-uhid doesn't declare CenterPad in its capability list so the motion only reaches the touchpad target. But the buttons can't follow (no translations exist), so mapping them just swallows the clicks and you're left with tap-to-click only.
I realize the stateless InputValue::translate() can't do absolute-touch→relative-mouse on its own (it needs the previous position); the touchpad target device already does that conversion internally, so perhaps that logic could be reused at the composite-device level when a profile requests touchpad → mouse.
Investigated and written with assistance from Claude (Anthropic).
Environment
inputplumber 0.78.1-1.1)83N0), composite device from50-legion_go_2.yamlTouchpad:RightPad:Touch:Motion,Touchpad:RightPad:Touch:Button:{Touch,Press}What I tried
A device profile that routes the physical trackpad to a plain mouse pointer, keeping it out of the
deck-uhidemulation (use case below):The schema (
device_profile_v1.json) accepts both mappings.What happens
Both translations are unimplemented at runtime, so the events are swallowed (trackpad goes completely dead) with one warning per event:
Looking at
src/input/event/value.rs(the// TODO: Implement all possible translationsblock):Touchpad … Touch::Motion→Mouse::Motionis an explicitTranslationError::NotImplemented(marked// TODO:).Touch::Button(_)as a source returnsNotImplementedfor every target, so touchpad button events cannot be remapped to anything at all.Why it matters (use case)
On desktop sessions, Steam hijacks any emulated trackpad (Deck and DualSense targets both) into its on-screen-keyboard typing mode whenever the OSK opens. The only clean way out is to keep the physical trackpad out of the gamepad emulation entirely and deliver it as a plain pointer — exactly what the mapping above expresses.
Partial workaround I found: remap
RightPad → CenterPadmotion (implemented, plain clone) with thetouchpadtarget added —deck-uhiddoesn't declare CenterPad in its capability list so the motion only reaches the touchpad target. But the buttons can't follow (no translations exist), so mapping them just swallows the clicks and you're left with tap-to-click only.I realize the stateless
InputValue::translate()can't do absolute-touch→relative-mouse on its own (it needs the previous position); the touchpad target device already does that conversion internally, so perhaps that logic could be reused at the composite-device level when a profile requeststouchpad → mouse.Investigated and written with assistance from Claude (Anthropic).