Bug 2401613 - HTIX5288:00 0911:5288 touchpad reports correct BTN_TOOL_* events but libinput interprets finger count as N-1 (off by one)
Summary: HTIX5288:00 0911:5288 touchpad reports correct BTN_TOOL_* events but libinput...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: libinput
Version: 42
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
URL: https://claude.ai/public/artifacts/19...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-10-05 00:39 UTC by Wowa
Modified: 2026-06-09 13:12 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2026-06-09 13:12:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
freedesktop.org Gitlab libinput libinput issues 1201 0 None opened HTIX5288:00 0911:5288 touchpad finger detection off by one (BTN_TOOL events correct, libinput misinterprets) 2025-10-10 01:22:49 UTC

Description Wowa 2025-10-05 00:39:10 UTC
The touchpad on LapBook Pro laptops with HTIX5288:00 0911:5288 (vendor 0911, product 5288) exhibits incorrect finger detection in libinput. The kernel correctly reports finger counts via BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, and BTN_TOOL_QUADTAP events (verified with evtest), but libinput consistently interprets these as one fewer finger than actually present.
Technical verification:

Kernel events are correct: evtest shows BTN_TOOL_DOUBLETAP when 2 fingers touch, BTN_TOOL_TRIPLETAP for 3 fingers, etc.
libinput behavior is wrong: 1 finger produces no/erratic pointer movement, 2 fingers act as single-finger pointer movement, 3 fingers trigger two-finger scrolling

Device information:

Device name: HTIX5288:00 0911:5288 Touchpad
Vendor/Product: 0911:5288
Bus: i2c (I2C-HID)
Physical size: 110x63mm
Max coordinates: X: 2628, Y: 1332
Resolution: X: 24 units/mm, Y: 21 units/mm
Laptop: LapBook Pro (DMI: "Manufacturer: Not Specified, Product Name: LapBook Pro")

Comparison with working configuration:
The same hardware works correctly on Puppy Linux using xf86-input-synaptics driver, which uses pressure-based finger detection (Synaptics Finger threshold: 25, 30, 0). This suggests libinput's BTN_TOOL_* event interpretation logic has incorrect assumptions for this specific touchpad variant.
Failed workaround attempts:

libinput quirks file - quirks system not functional on test system
hwdb evdev calibration - caused complete touchpad failure (no movement)
hid_multitouch kernel module parameters - none available

Reproducible: Always

Steps to Reproduce:
1. Install Linux distribution with libinput (tested on Fedora Silverblue 42, GNOME Wayland)
2. Use laptop with HTIX5288:00 0911:5288 touchpad (LapBook Pro or similar)
3. Touch touchpad with 1 finger and attempt to move pointer
4. Touch touchpad with 2 fingers and attempt to scroll
5. Verify kernel events: sudo evtest /dev/input/eventX | grep BTN_TOOL (replace X with touchpad event number)
Actual Results:
1 finger: Cursor jumps erratically or doesn't move
2 fingers: Pointer movement (single-finger behavior)
3 fingers: Two-finger scrolling
4 fingers: Three-finger gesture
Kernel correctly reports: BTN_TOOL_FINGER (1), BTN_TOOL_DOUBLETAP (2), BTN_TOOL_TRIPLETAP (3), BTN_TOOL_QUADTAP (4)

Expected Results:
1 finger: Pointer movement
2 fingers: Two-finger scrolling
3 fingers: Three-finger gesture
4 fingers: Four-finger gesture
libinput should correctly interpret the kernel's BTN_TOOL_* events

Additional Information:
**evtest output samples:**

One finger touch:
```
Event: type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 1
```

Two finger touch:
```
Event: type 1 (EV_KEY), code 325 (BTN_TOOL_FINGER), value 0
Event: type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 1
```

Three finger touch:
```
Event: type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 0
Event: type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 1
```

**libinput device info:**
```
Device:                  HTIX5288:00 0911:5288 Touchpad
Kernel:                  /dev/input/event9
Size:                    110x63mm
Capabilities:            pointer gesture
Tap-to-click:            disabled
Scroll methods:          *two-finger edge
Click methods:           *button-areas clickfinger
Disable-w-typing:        enabled
```

**Existing libinput quirk for related devices:**
The file `/usr/share/libinput/30-vendor-synaptics.quirks` contains:
```
[Synaptics 0911:5288 Touchpad]
MatchUdevType=touchpad
MatchName=* 0911:5288 Touchpad
AttrEventCode=-BTN_RIGHT
```
This matches other 0911:5288 variants (SYNA3602, ALPS0001, PCT2342) but not HTIX5288:00 prefix.

**Observed anomalies:**
During testing, evtest occasionally showed coordinate values far beyond valid range (43007, 46079, 63489 vs max 2628, 1332). These may be palm rejection artifacts but don't appear to be the root cause, as BTN_TOOL_* events remain correct.

**System information:**
- Distribution: Fedora Silverblue 40/41
- Desktop: GNOME Wayland
- libinput version: (latest in Fedora repos as of 2025-10-05)
- Kernel: (recent 6.x series)

Comment 1 Wowa 2025-10-05 00:56:39 UTC
I'm highly motivated to help resolve this issue. This is my sister's laptop and I don't want her to live in the tyranny of Windows 11, but all the major distros have this problem with the touchpad and I'm ashamed to give up on my quest of liberation!
I have programming knowledge and can build, find, test, refine, whatever is needed if some instructions are given - as long as they have light at the end in the form of a properly working touchpad and the laptop consequently, and not just busy work that I do not understand.
I'm ready to:

Build and test patches
Try experimental fixes
Collect additional diagnostics
Test on the actual hardware
Iterate through multiple solution attempts

If there are specific parts of the libinput codebase I should look at, or if you need someone to test patches on this exact hardware (HTIX5288:00 0911:5288), please let me know. I'm committed to seeing this through to a working solution.

Comment 2 Fedora Release Engineering 2026-05-06 14:29:58 UTC
This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 3 Aoife Moloney 2026-06-09 13:12:42 UTC
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.