Summary: | hms(4): two finger scroll stops half way unless dev.hms.0.drift_thresh=0 | ||
---|---|---|---|
Product: | Base System | Reporter: | Edward Tomasz Napierala <trasz> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | New --- | ||
Severity: | Affects Only Me | CC: | emaste, markj, wulf |
Priority: | --- | ||
Version: | 15.0-CURRENT | ||
Hardware: | Any | ||
OS: | Any | ||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276708 |
Description
Edward Tomasz Napierala
2024-01-29 12:57:19 UTC
Could you try to increase sysctl dev.hms.0.drift_thresh rather than set it to 0? It is better with it set to eg 10, but it still occasionally gets stuck. I wonder... From what I understand it tries to detect and filter out repeating inputs. What if the problem happens because, differently from cursor movement which is kind of random: event6 POINTER_MOTION +0.536s 7.86/ 5.24 ( +6.00/ +4.00) event6 POINTER_MOTION +0.546s 7.76/ 1.29 ( +6.00/ +1.00) event6 POINTER_MOTION +0.556s 4.49/ 1.12 ( +4.00/ +1.00) event6 POINTER_MOTION +0.566s 2.00/ 0.00 ( +2.00/ +0.00) event6 POINTER_MOTION +0.576s 3.00/ -2.00 ( +3.00/ -2.00) event6 POINTER_MOTION +0.586s 2.00/ -3.00 ( +2.00/ -3.00) event6 POINTER_MOTION +0.596s 2.03/ -4.05 ( +2.00/ -4.00) event6 POINTER_MOTION +0.606s 0.00/ -6.82 ( +0.00/ -6.00) event6 POINTER_MOTION +0.616s 0.00/ -7.32 ( +0.00/ -6.00) event6 POINTER_MOTION +0.626s -5.32/ -9.31 ( -4.00/ -7.00) event6 POINTER_MOTION +0.636s -7.37/-10.32 ( -5.00/ -7.00) event6 POINTER_MOTION +0.646s -2.48/ -3.72 ( -2.00/ -3.00) event6 POINTER_MOTION +0.656s -3.01/ -3.01 ( -3.00/ -3.00) event6 POINTER_MOTION +0.666s -3.01/ -1.00 ( -3.00/ -1.00) event6 POINTER_MOTION +0.676s -2.00/ 0.00 ( -2.00/ +0.00) event6 POINTER_MOTION +0.686s -1.00/ 0.00 ( -1.00/ +0.00) event6 POINTER_MOTION +0.696s -2.00/ 0.00 ( -2.00/ +0.00) The scroll events in all direction look mostly the same: event6 POINTER_SCROLL_WHEEL +0.784s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +0.814s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.164s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.184s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.204s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.234s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.544s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.564s vert 15.00/120.0* horiz 0.00/0.0 (wheel) event6 POINTER_SCROLL_WHEEL +1.584s vert 15.00/120.0* horiz 0.00/0.0 (wheel) So perhaps the threshold logic is mistaking them for duplicates? Here's a prototype patch: https://reviews.freebsd.org/D47640. I still need some advice on how to proceed: whether that's the right approach, and how to figure out which of the report variables is the wheel. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c0a5ee953f41905038aadba7b7d0df2af6612e71 commit c0a5ee953f41905038aadba7b7d0df2af6612e71 Author: Edward Tomasz Napierala <trasz@FreeBSD.org> AuthorDate: 2024-11-25 15:08:10 +0000 Commit: Edward Tomasz Napierala <trasz@FreeBSD.org> CommitDate: 2024-11-26 10:28:51 +0000 hms(4): improve scroll with IICHID_SAMPLING The current quirk is designed to discard duplicated data read from the chip. Problem is, it also discards real events when they happen to be identical, which is the case with scroll wheel events; differently from X/Y they always move by fixed offset. This results in two-finger scroll that would stop mid-way that could be fixed by manually setting dev.hms.0.drift_thresh to 0. To fix that, don't discard duplicates when there's wheel movement. For users with actual duplicates problem this will result in scroll suddenly becoming quite inertial, but it will stop moving at any touch, so shouldn't be terrible. PR: kern/276709 Reviewed By: wulf Differential Revision: https://reviews.freebsd.org/D47640 sys/dev/hid/hms.c | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) |