Recently switched to Linux on my Dell Precision 7510 and noticed a
jittery/shaking effect when scrolling slowly with the touchpad, across
multiple applications.
libinput measure fuzz reported no fuzz value set for the touchpad's
axes, which explains the jitter (sensor noise being read as real
motion). Used libinput measure fuzz --fuzz=28 to generate and apply a
hwdb override, then confirmed scrolling was smooth afterward.
Added a new entry to hwdb/60-evdev.hwdb for this device:
evdev:name:AlpsPS/2 ALPS DualPoint
TouchPad:dmi:*:svnDellInc.*:pnPrecision7510*:
This is the same touchpad family as #34133 (Dell Latitude E7440), which
hit the same symptom and fix — this PR extends the coverage to the
Precision 7510.
The Goodix Capacitive TouchScreen on the AYANEO Flip KB reports an
invalid calibration range during boot, due to unreliable I2C
communication with the touch controller early in the boot sequence.
Observed values include ABS_X max as high as 65343 and ABS_Y max as
low as 256, far outside the panel's actual resolution.
Confirmed on real hardware across multiple cold boots that the
controller never reports a correct calibration on its own, including
after forcing driver re-probes via unbind/bind. Override the axis
ranges with the panel's real resolution (1200x1920).
Also covers the Flip DS, mostly identical to the Flip KB apart from a
second screen replacing the keyboard. Not independently verified on
Flip DS hardware, but consistent with a community report of the same
Y-axis maximum (1919) for that model's main display, using a
different (and seemingly non-functional) override syntax.
Note: the panel is also mounted rotated relative to the raw sensor
axes; this entry only fixes the calibration range, not rotation (most
desktop environments handle touch rotation automatically when the
display output is rotated, independent of this).
The Lenovo B570e touchpad (ETPS/2 Elantech) reports ABS ranges that
are too wide by default, which makes edge scrolling trigger across
roughly the right half of the touchpad instead of only at the right
edge. Add an evdev hwdb entry in `60-evdev.hwdb` that overrides the
ABS_X/ABS_Y (and the matching MT position) ranges with the calibrated
values, following the same pattern already used for the Lenovo B590
and L430 entries.
Fixes#29666
The Goodix GXTP5100 touchpad (HID bus 0x0018, vendor 0x27C6, product
0x01E9), found in the Lenovo ThinkBook 16 G7+ IAH and ThinkPad X9 15
Gen 1, has a kernel driver bug where ABS_PRESSURE (axis 24 / 0x18) is
reported with min=0, max=0.
This invalid axis range causes libinput to reject the device with:
"kernel bug: ABS_PRESSURE has min == max (both 0)"
The touchpad hardware itself is functional and reports valid ranges for
all other axes:
ABS_X: min=0, max=4149, resolution=31
ABS_Y: min=0, max=2147, resolution=27
ABS_MT_POSITION_X/Y: valid ranges
Root cause: the kernel hid-multitouch driver applies a "GT7868Q report
descriptor fixup" to this device (the HID descriptor is malformed and
fails hid-generic probe with EINVAL). The fixup corrects most axes but
leaves ABS_PRESSURE with an invalid 0:0 range.
This hwdb entry overrides ABS_PRESSURE to a valid 0:255 range, allowing
libinput to accept and initialize the device.
Kernel version: 6.17.0-19-generic
Device path: /sys/bus/hid/drivers/hid-multitouch/0018:27C6:01E9.0001
The "AIPTEK Media Tablet Ultimate", detected as "Waltop International Corp. Batteryless Tablet",
is missing the resolution of the x-/y-axes.
Adding a new rule to 60-evdev.hwdb with the same values as another entry
"WALTOP International Corp. Batteryless Tablet" just with another matching string makes the
device usable.
Fixes#33362.
This solves Debian Bug report 1008760:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008760.
Solution was inspired by this kernel bug report message:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c15.
My measured pad dimensions with a ruler were 85x44mm.
But I decided to take the 2x size reported by the current kernel
when invoking the touchpad-edge-detector command from the
libdev-tools package. Because this comment claims that the old
vs new kernel reportings differ by factor 2:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c3 .
Therefore I have used this command to get the new entry to 60-evdev.hwdb:
"root@pb:~# touchpad-edge-detector 80x34 /dev/input/event2
Touchpad ETPS/2 Elantech Touchpad on /dev/input/event2
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..1254], y [0..528]
Touchpad sends: x [0..2472], y [-524..528] -^C
Touchpad size as listed by the kernel: 40x17mm
User-specified touchpad size: 80x34mm
Calculated ranges: 2472/1052
Suggested udev rule:
# <Laptop model description goes here>
evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnPackardBell:bvrV1.21:bd08/09/2012:br21.240:svnPackardBell:pnEasyNoteTS11HR:pvrV1.21:rvnPackardBell:rnSJV50_HR:rvrBaseBoardVersion:cvnPackardBell:ct10:cvrV1.21:*
EVDEV_ABS_00=0:2472:31
EVDEV_ABS_01=-524:528:31
EVDEV_ABS_35=0:2472:31
EVDEV_ABS_36=-524:528:31
"
This fixes the discrepancies in the coordinate ranges for the touchpad, touchpad in this device(NS13A2) is generic and the same one is used in most models.
We've had this text since the beginning, but in fact the patterns must be
stable in order for people to create local hwdb entries. And we support that
and can't change the match patterns without being very careful. So let's just
drop the text.
The Pinebook Pro touchpad returns a resolution data that is 2 times of
the real value, which makes libinput think the touchpad is only 1/4 the
real size.
Add a resolution override value for it, to allow libinput to calculate
the distance moved on it correctly.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>