Re: [PATCH v2 3/5] Input: hynitron-cst816x: release gesture keys
From: Daniel Golle
Date: Mon Oct 05 2026 - 13:08:11 EST
Hi!
Thank you for testing, and for reporting the issue.
> I suggest either gate the gesture branch on tch.active so a finger-up
> single-click never fires a key, or fix cst816x_gest_idx() to map 0x5/0xC
> to their own valid slots so they stop aliasing the TRIPLETAP keycode.
v3 takes the second route. cst816x_gest_idx() returned
CST816X_NUM_KEYS - 1 for every code its switch did not name, so single
click, 0x05, shared the long-press slot. Reporting the key with a
fixed value of 1 is what made that alias visible as the
BTN_TOOL_TRIPLETAP pair in your log.
The lookup now yields a keycode instead of an index:
static unsigned int cst816x_gest_keycode(struct cst816x_priv *priv,
u8 gest)
{
switch (gest) {
case 0x01: /* Slide up gesture */
case 0x02: /* Slide down gesture */
case 0x03: /* Slide left gesture */
case 0x04: /* Slide right gesture */
return priv->keycode[gest - 1];
case 0x0c: /* Long press gesture */
return priv->keycode[CST816X_NUM_KEYS - 1];
default:
return KEY_RESERVED;
}
}
A code the driver does not map is handled like a report that carries
no gesture code at all: it releases whatever the input core still
holds down, rather than pressing a key that belongs to another
gesture. Single click reports nothing of its own, so a tap is
described by BTN_TOUCH alone.
I left the gate on tch.active out, because your trace shows the
gesture codes arriving with t: 0 on both the finger-down and the
finger-up report, and that t is tch.active. Slide gestures reach the
driver the same way, at lift, so the gate would silence the keys this
series is meant to report, not only the single click.
If a key for single click is wanted, that is a linux,keycodes
extension in the binding and can follow on its own.
v3 with that change follows. A retest on your CST816S would be most
welcome.