Support level-coded SW input on hardware reporting KEY_1 (Stargate)

[phischmi]

Problem

On a Wall Display Stargate (SAWD-0A1XX10EU1) the SW terminal does nothing: no switch_state on MQTT, no relay toggle, no JS event. The key event is delivered to the app — dumpsys input shows it reaching MainActivity — but it is dropped.

The cause is that the terminal is reported in a second scheme that the keymap does not know.

The implemented scheme is edge coded: each contact transition is a short key pulse whose keycode carries the direction (141/KEY_F11 rising, 142/KEY_F12 falling), verified on the X1i.

The Stargate's gpio_keys node declares exactly one code and nothing else:

N: Name="gpio_keys"
B: EV=3          (EV_SYN + EV_KEY, no EV_SW)
B: KEY=4         (bit 2 -> KEY_1, scan code 2, Android keycode 8)

Here the contact level is the key state — down while the line is active, up when it goes inactive, with Android auto-repeating the down while it is held:

action=0 keyCode=8 repeatCount=44..49   <- auto repeat while held (~3 s)
action=1 keyCode=8 repeatCount=0        <- release

levelForAndroidKey(8) returns null, so SwInputHandler declines the key, MainActivity falls through to super.dispatchKeyEvent() and the edge is lost.

Change

Decode both schemes in the keymap and handle them on both intake paths — the activity KeyEvents and the native input monitor including its getevent fallback. Everything downstream is unchanged: SwInputStateMachine applies the configured mode, publishSwitch() sends PRESS/RELEASE, the relay and JS paths are untouched.

No per-model flag. The two code sets are disjoint, so a model reporting either scheme works without a DeviceModel entry — including Atlantis and Pegasus, which I cannot verify for lack of hardware.

KEYCODE_1 is an ordinary digit on a real keyboard, so unlike the F11/F12 pulses it is only claimed when the model has an SW input and the reporting input device has no letter keys (hasKeys(KEYCODE_Q)). gpio_keys declares the one SW code; a USB or Bluetooth keyboard keeps its digit and passes through to the webview. The verdict is memoized per deviceId, so there is no lookup per auto-repeat.

Verification

On a Stargate, with the real wired push-button, swInputMode0=1 (Button):

14:54:35.395  input=false relay=false     <- baseline
14:55:04.981  input=false relay=true      <- relay toggles on the rising edge
14:55:05.112  input=true  relay=true      <- contact held
14:55:08.108  input=false relay=true      <- released ~3.0 s later, relay stays

GET /device/input?num=0 reports state: true for the full hold and false on release. Verified with the screensaver activity in front as well as MainActivity, since both route through SwInputHandler. Unit tests cover the extended keymap.

Note on the first commit

481a1f6 is unrelated to the SW input: 3d13d7f added a Build.VERSION.SDK_INT check to WakeWordDetector.buildInterpreter() without importing android.os.Build, which breaks compileDebugJavaWithJavac on main. It is in here because the branch does not build without it — happy to split it into its own PR if you prefer.

🤖 Generated with Claude Code