HID: asus: emit PROG1/PROG2 for the AC/CC front buttons

[jlobue10]

Follow-up to #8 ("Now only AC/CC are missing"): maps the two front buttons to stable keycodes on short and long presses.

button	short	long	keycode
AC (hexagon; top-LEFT on Xbox Ally X, hw-confirmed)	raw 0xA6 (was F16)	kbd usage 0x70	KEY_PROG1
CC (top-RIGHT on Xbox Ally X)	vendor 0x93	kbd usage 0x71	KEY_PROG2

Design notes:

• Raw 0x38/0xA7 keep PROG1 — 0x38 follows the ROG-key convention, and 0xA7 is the long-press companion of the 0xA6 button on the ROG Ally X, so short/long must agree. Net effect: the ROG Ally X gets the same per-scancode behavior as the Xbox Ally X even though its physical button placement differs.
• Vendor-page 0xa6/0xa7 (original ROG Ally, where CC/QAM really is 0xa6) become PROG2/PROG1 by name; the laptop ROG key path is untouched.
• Comments identify buttons by name only — placement differs between Ally generations.
• Resume ghost-release + input capabilities follow the new keycodes (F16/F17 dropped, PROG2 added).

One open question: does the gen-1 Ally ever deliver 0xA6/0xA7 through the raw 0x5A path (handle_ally_event)? If it does, its CC button would emit PROG1 there instead of the vendor-page PROG2 — happy to gate that differently if so.

Validated on Xbox Ally X (RC73XA, MCU 0b05:1B4C) against ally head eb5d9d5:

• 4/4 guided front-button checks — left short/long → PROG1 (long scan 0x70070), right short/long → PROG2 (short scan 0xff310093, long 0x70071), no stray F16/F17/F21/F22
• full 25-button matrix pass
• 41/41 checks across 3 suspend/resume cycles (ghost-release exercised on every resume)

🤖 Generated with Claude Code

[jlobue10]

Updated: squashed in comment-only documentation of the M1/M2 rear paddle orientation (M1 = right rear, M2 = left rear) while touching this file — annotated at the button-id enum, the remap code table, the vendor-page 0xa5 mapping, and the turbo config struct (whose M2-before-M1 field order matches the firmware payload). No functional change beyond the original scope; still a single commit (7fee37e).

[jlobue10]

Follow-up: pushed 1698eeb ("HID: asus: emit Ally front-button long-press once, on release") — hardware-validated on the Xbox Ally X (FW FGA80100.RC73XA.325, 7.2.0-rc4 base).

The gap

The v2 mapping delivered the right keycodes, but a long press behaved as a held key: evdev capture shows PROG down ~200ms into the press, continuous autorepeat while held (115–125 repeat events over a ~4.5s hold), and up at release. The set_bit(EV_REP) lines in v2 turn out to be no-ops either way — hid-input already enables EV_REP on keyboard nodes, which is where the repeats come from.

Transport ground truth from a raw evdev dump of the unpatched build (all four gestures cued so press/release instants are known):

gesture	wire	edge behavior
AC short	vendor 0x5A/0xA6, no scan	synthesized tap
AC long	kbd usage 0x70, scan 0x70070	down ~200ms after press, EV_REP repeats, up at release
CC short	vendor 0x93, scan 0xff310093	press/release pair
CC long	kbd usage 0x71, scan 0x70071	same held-key shape as AC long

Two corrections to earlier statements: the long-press make lands ~200ms after the physical press (the MCU threshold — not ~2s as I previously wrote), and taps under that threshold never emit the kbd usage at all.

The fix (1698eeb)

Same approach as the existing 0xA8 → 0x00 rewrite: asus_raw_event() strips usages 0x70/0x71 from the keyboard report (6-slot array + NKRO bitmap, report ID 0x01) before the generic parser sees them, tracks held state in drvdata, and synthesizes the complete press+release pair — with the matching MSC_SCAN — on the break. The tracked state is cleared in both resume paths so a break lost across suspend can't turn the next keyboard report into a phantom pair.

Result: short and long presses deliver the identical shape — exactly one PROG1 (AC) / PROG2 (CC) press+release pair, nothing while the button is held, no autorepeat.

Validation (same boot, srcversion 0AC33637 memory-swap of this branch's file)

test	result
front-button matrix, v2 baseline	6/8 — both longs fail on autorepeat-while-held (the gap above)
front-button matrix, this commit	8/8 — longs emit once, on the release edge (first event t=5.47s/5.73s vs release cue t=5.01s), correct scancodes preserved
full 25-button matrix (sticks, triggers, paddles, fronts)	25/25
suspend/resume s2idle ×3 (front-button checks each cycle)	41/41, kmsg clean
suspend/resume mcu_powersave ×2 (forces reset_resume)	29/29, kmsg clean

Happy to rework or squash into the v2 commit if you'd rather keep the branch to one commit.