Swipe up on the keys to accept a suggestion cannot be turned on: `trackpad_gestures_enabled` has had no screen since 1.0.2

[djbclark]

What happened

Flicking up on the physical keys to take a word suggestion does nothing on a fresh 2.0.x install, and there is no setting anywhere to turn it on.

Why (from the code on legacy-2.x)

• trackpad_gestures_enabled defaults to false in SettingsManager.kt, and both gesture providers are gated on it.
• The only code that sets it true is applyDevsChoiceSettings() in TutorialActivity.kt, which has had no callers since the onboarding rewrite.
• The "Keyboard swipe" settings screen was removed in a5ce9a1 (1.0.2). The change note says the Shizuku-backed keyboard-surface trackpad was "superseded" by the screen trackpad, but that is a different feature (moving the cursor); swipe-to-accept has no other trigger.
• So the gesture is only on for someone whose preference survived from before 1.0.2 or came in through a backup restore. Confirmed on my phone: the preference is absent from physiboard_prefs.xml.
• The 3.0 spec already records the gap: settings-catalog.md §2.2 says "No screen in 2.x", trackpad-caret-nav.md §3.2 says nothing turns it on, and §13 there leaves the native provider "undecided, needs a capture on the phone before deciding".

Asks

1. For 3.0: keep the native provider and give its rows a screen (Keyboard > Keyboard swipe: enable switch, add-word switch, swipe distance). Proposed Keep/Drop wording: docs(spec): keep the long-press and keyboard-swipe rows with a screen in 3.0 #12.
2. I can provide the capture the spec asks for, from a Titan 2 Elite on V02.00.04 / Android 16: with the preference forced on, what the decor-view listener receives for an up-swipe (device name, source, coordinate range, whether Unihertz's Scroll Assistant or flick-typing system settings gate delivery, and where the thirds fall on the 1080-wide layer). I will post it here.

Meanwhile

My fork carries a small Keyboard swipe settings screen on top of legacy-2.x (branch keyboard-swipe-setting, https://github.com/djbclark/physiboard) for anyone who needs the gesture on 2.x.

PhysiBoard version

2.0.7 (built from legacy-2.x)

Phone

Unihertz Titan 2 Elite, Titan 2 Elite_V02.00.04, Android 16

[djbclark]

For anyone on 2.x who wants the gesture now: a fork build of 2.0.7 with a Keyboard → Keyboard swipe screen (plus the #9 Long Press screen and the #14 right-third fix) is at https://github.com/djbclark/physiboard/releases/tag/v2.0.7-djbclark.1. Debug-signed, so it does not install over the upstream build; the notes there explain the uninstall and IME re-select.

[djbclark]

The capture promised above, from Titan 2 Elite_V02.00.04, Android 16, with trackpad_gestures_enabled forced on and the native provider active.

A flick up on the keys never reaches the IME as touchpad motion. With the decor-view listener attached, not one SOURCE_TOUCHPAD MotionEvent was logged across several flicks. dumpsys input shows why the reader treats the surface differently from a plain touchpad:

Device 6: touchPad
  Sources: KEYBOARD | TOUCHPAD
    X: source=TOUCHPAD, min=0, max=1079
    Y: source=TOUCHPAD, min=0, max=748.75
  Touch Input Mapper (mode - DIRECT):
    GestureMode: MULTI_TOUCH
    AssociatedDisplay: hasAssociatedDisplay=true

What arrives instead is a synthetic key event. At the moment of each flick, system_server logged:

I/A85ShortcutFunction: <handleEvent>, event=KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_DPAD_UP, scanCode=19, metaState=0, repeatCount=0, deviceId=6, source=0x101 ... }
I/AguiKeyboardShortcut: isHomePackage:<KeyCode>, keycode=19 ... focusApp=com.rhmsoft.edit.pro/...
D/PhysiBoardInputMethod: onUpdateSelection old=(343,343) new=(339,339)

deviceId=6 is the touchPad device, source=0x101 is SOURCE_KEYBOARD, and scanCode=19 equals the keycode (the kernel's KEY_UP would be 103), so it is synthesized, not a firmware key. A flick down is KEYCODE_DPAD_DOWN, scanCode 20. Unihertz's Scroll Assistant was off. The IME passes the key through today, which is why a flick moves the caret a line in the editor.

Raw getevent -l /dev/input/event4 confirms the hardware itself only reports BTN_TOUCH plus ABS_MT_POSITION_X/Y for finger contact; the D-pad key is added above the kernel.

Consequence for 3.0: on the Elite the motion-event provider cannot work; the swipe has to be taken as a KEYCODE_DPAD_UP key event from the touchPad device, the same shape as the existing titan2_keycode swipe-to-delete provider (keycodes 322/404). A key event carries no X, so only the centre suggestion can be picked; left/right thirds are not available on this firmware. Added to the spec PR (#12) as device fact D7. I'm implementing that keycode path on my fork now and will report whether it works end to end.

This also resolves #14 for the Elite in practice: the third calculation only matters for the motion provider, which never fires here.

[djbclark]

Correction and result. Tested end to end on the Elite today with the fork build (trackpad_gestures_enabled on, native provider):

• The KEYCODE_DPAD_UP events in my previous comment were not from a flick. They came from Unihertz's double-tap Cursor Assistant mode, which synthesizes D-pad keys for drags. Please disregard that part; the docs PR (docs(spec): keep the long-press and keyboard-swipe rows with a screen in 3.0 #12) has been corrected (D7).
• A real flick works, but only with Scroll Assistant on (Settings > Gestures > Keyboard gestures). With it on, the IME's focused decor view receives SOURCE_TOUCHPAD (0x100008) motion events from deviceId=6 touchPad; with it off, nothing reaches the IME at all.
• 11 flicks were accepted and inserted suggestions ("goods", "for", ...). All three thirds were reached: starts at x=232 (left), 608–652 (centre), 840–875 (right). The x=840 flick lands in the right third only with the device-range boundaries from Keyboard swipe: the right-hand suggestion is almost unreachable because thirds are computed against a 1440 px surface on the Elite's 1080 px touch layer #14; under the 1440 px rule it would have been centre.
• Event coordinates are display-scaled, not the axis range dumpsys reports. Flicks started at y 907–987 and ended at 516–685 (display is 1080×1200). A natural flick covers 280–470 px in 80–150 ms (2.5–4.3 px/ms).
• The default trackpad_suggestion_swipe_threshold of 500 px rejects most natural flicks. Mine were accepted at 270. Suggest a lower default for the Elite, or a threshold expressed as a fraction of the pad.

Sample accepted line:

D/TrackpadDebug: Native swipe accepted[up]: direction=UP startX=641.0, startY=913.75, x=..., y=620.0, dx=..., dy=-293.75, duration=109ms, velocity=2.69, xMax=1079.0, third=1

So for 3.0: keep the native provider, take thirds from the device's X range, lower the threshold default, and tell the user that Scroll Assistant must be on. The fork build for 2.x will carry that note.

[djbclark]

Fork build 2 with the end-to-end result folded in: the Keyboard swipe screen now says Scroll assistant must be on, and the default suggestion swipe distance is 200 px (500 rejected most natural flicks; incidental touches stay under 100 px). https://github.com/djbclark/physiboard/releases/tag/v2.0.7-djbclark.2

[djbclark]

Swipe-to-delete has the same gap, confirmed on the Elite today with Scroll Assistant on: left flicks reach the native provider fine (168 to 684 px, mostly 190 to 415, at 2 to 7 px/ms), but swipe_to_delete defaults to false with no screen since 1.0.2, and the 500 px trackpad_delete_swipe_threshold rejects almost all of them anyway. Sample rejected candidate:

Native candidate[up]: ... left=415.0, deleteThreshold=500.0, duration=138ms, leftVelocity=3.0, leftEnough=false, mostlyHorizontal=true, horizontalFastEnough=true

Folded into PR #12's Keyboard swipe row (switch plus distance slider, lower default). The fork build will carry both.

[djbclark]

Swipe-to-delete confirmed working on the Elite with fork build 3 (switch on, 200 px distance, Scroll Assistant on): a left flick on the keys deletes the previous word. Both keyboard-surface gestures now work end to end on 2.x with only settings changes; no gesture code was altered. https://github.com/djbclark/physiboard/releases/tag/v2.0.7-djbclark.3