Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Dec 2024 19:57:31 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 262282] Framework laptop touchpad latency
Message-ID:  <bug-262282-227-mufjXLppRm@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-262282-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-262282-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262282

--- Comment #12 from Vincent Milum Jr <freebsd@darkain.com> ---
I think part of the issue is just FreeBSD's underlaying touchpad code, not =
even
specific to this exact touchpad.

I have another laptop that has a 144Hz screen on it, but I noticed the touc=
hpad
in FreeBSD was only polling at ~60Hz. When there is such a large discrepancy
between screen refresh rate and pointer polling, it becomes significantly m=
ore
noticeable.

Latency issue or not (I don't remember if that machine also had that issue),
due to the fact that there is mouse movement smoothing as well, multiple in=
puts
would need to be captured for the smoothing to kick in and then produce a
response back to the rest of the stack and ultimately the cursor update on
screen.

So the first two things I'd suggest investigating is the polling frequency =
and
the code used for cursor smoothing.

As an additional note: on that laptop with the 144Hz screen (some random De=
ll I
have), I tried tweeking the polling frequency directly in the driver it use=
s. I
could only push it as far as about 120Hz before input became entirely unsta=
ble.
I didn't really check into seeing if this was an issue with the hardware or
somewhere in the driver/kernel.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262282-227-mufjXLppRm>