There is observable latency between certain touchpad actions and mouse movement. In the vt(4) console with moused running if I start without touching the touchpad, then touch and immediately move my finger there seems to be a delay of about 3/4 of a second before the cursor starts moving. If I place my finger on the touchpad but wait at least a second before moving there is a short (just barely perceptible) delay before the cursor moves. There is little delay while in X - seems to be barely perceptible if starting without touching the touchpad, and imperceptible if starting with a finger on the touchpad. FreeBSD main and drm-kmod master as of Feb 24 2022.
In my particular case, the latency even in xorg is still very noticeable. It isn't the full ~1s delay as seen on the console, but it is probably somewhere in the neighborhood of 100ms. This delay is NOT seen when using Windows on the same laptop, and makes it a little frustrating to actually use with FreeBSD, as a user who is extremely sensitive to latency. The latency on FreeBSD isn't just the initial movement, it is continual throughout the entirety of moving the cursor on the screen, the feedback is always ~100ms behind the actual input being given. This same latency is NOT seen when using an external USB mouse on the same machine.
In BIOS PS/2 Emulation was set to "Auto". Changing it to "Disabled" addresses vt(4) latency (because the trackpad no longer moves the cursor at all). In X the trackpad seems fine. Vince, can you check the state of the BIOS setting, and if currently set to Auto retry with it set to Disabled?
Hi, I'd like to provide some explanation from Framework engineering. The Framework EC detects if there is any I2C communication with the touchpad, and if there isn't it'll enable PS2 emulation. This was added because the Windows Installer does not have an I2C driver for Intel systems. Anything else (Installed Windows, Linux and as it seems FreeBSD) does not need this. So it is safe to disable PS2 emulation in BIOS settings to avoid it triggering on accident. Maybe on FreeBSD it triggers because of some timing differences. The code for Intel 11th to 13th Generation is here, for reference: https://github.com/FrameworkComputer/EmbeddedController/blob/hx20-hx30/baseboard/fwk/ps2mouse.c
I've recently replaced my FrameWork laptop motherboard going from 11th Gen Intel to 13th Gen Intel. At the same time, I replaced FreeBSD 14-CURRENT with 15-CURRENT. With or without the PS/2 emulation enabled, there is still touchpad latency. The latency feels the same either way. The 100ms-ish latency is still there. And again, this latency isn't there when using Windows. This is most certainly something with the FreeBSD touchpad implementation. Using a wired USB mouse does not have similar latency.
(In reply to Vincent Milum Jr from comment #6) In order to determine where the issue originates it will be useful to know if the same issue affects a contemporary Linux distro (and the versions of the various related components, such as libinput). I will try to look at this at some point in the future if nobody else adds an update before I can get to it.
Stumbled across this report while tracking down a solution as I'm experiencing similar issues; in this case it is a mainstream albeit 2 year old Dell Latitude 7420. Device: input pointer-1160-4122-DELL0A36:00_0488:101A_TouchPad Running FreeBSD 14.1 and also 14.2-RC1. Very plain installation. Latency is... huge, making it virtually unusable for daily work. Tap to click often requires several stabs at a target to activate, which is difficult when the target is a closing tab X or a word selection. Pointer responsiveness seems unmanageable despite various libinput settings or no settings. Palm detection seems off, too. The behaviour is the same on FreeBSD whether running X/GNOME or Wayland/River WM. Booting off a USB to run a vanilla Linux distribution (two - Void Linux and openSUSE) with the same two desktop targets - no issues noted, very responsive. If there are tweaks I can try, or information I can capture to determine what is going on, am willing to assist.
(In reply to Mike Watkins from comment #8) Is there a PS/2 emulation option you can turn off in the system firmware?
(In reply to Ed Maste from comment #9) While the documentation for Dell Latitude 7420 and related devices suggests there is an option, my device does not offer any configuration tweaks in bios whatsoever related to the touchpad. The only HID device noted is keyboard (function key or media key lock). Dell bios options are quite extensive. The option might have been there in prior firmware, but I don't recall ever seeing it. Are there any tweaks or debug options I can enable to see if the PS2 issue is a factor? I've put 14.2-RELEASE on, fresh install, minimal Wayland config, and am seeing the same behaviour.
Note to add I also fired up an XOrg session, set touchpad parameters with xinput, and observed the same laggy/behaviour. Tap to click not working well is a dead giveaway. Same libinput but a night and day difference when Linux is handling the device, perhaps there are clues there. Being a Dell Latitude one expects the specific device is in a lot of machines.
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 touchpad in FreeBSD was only polling at ~60Hz. When there is such a large discrepancy between screen refresh rate and pointer polling, it becomes significantly more 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 inputs 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 Dell I have), I tried tweeking the polling frequency directly in the driver it uses. I could only push it as far as about 120Hz before input became entirely unstable. I didn't really check into seeing if this was an issue with the hardware or somewhere in the driver/kernel.