Gave FreeBSD 12.1-RC2 a test on my laptop. Under 12.0-RELEASE-p10, in an X11 session, the Synaptics touchpad on the laptop behaves as is expected of a touchpad device. Under 12.1-RC2, however, the touchpad is significantly slower (almost like acceleration is turned off), and clicking the button requires first moving the cursor with the touchpad. e.g., if one moves the cursor, the next click will register, but clicks after that will not register unless the cursor is moved again, or the cursor is moved while holding the button down. I tried tweaking a few of the sysctl variables, but I am not seeing any noticeable change in behavior. Seems like the way the device is being polled is incorrect. This is all dmesg says: psm0: <PS/2 Mouse> irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 3 My Xorg config for the touchpad is taken directly from the handbook: Section "InputDevice" Identifier "Touchpad0" Driver "synaptics" Option "Protocol" "psm" Option "Device" "/dev/psm0" EndSection And then in "ServerLayout": InputDevice "Touchpad0" "SendCoreEvents" I am running a custom kernel. It looks like the 12.1 GENERIC config adds evdev support to legacy drivers (options EVDEV_SUPPORT), but I am not seeing /dev/input/event* device nodes being created by anything. Some Google-searching indicates that the webcamd module is the only thing that will create and populate /dev/input with event cdves right now, however I want all webcam support disabled, so I can't test evdev to see if it works better than the classic synaptics driver.
Created attachment 208473 [details] psm0 debug lines from dmesg FWIW, I booted with 'debug.psm.loglevel=5' in loader.conf and captured some additional detail from dmesg in the attached text file. Got the idea by reading the comments in Bug #222609.
It looks like 12.1-RELEASE fixed this, in a way. /dev/input/eventX is populated now, and it took some tweaking of kern.evdev.rcpt_mask to get the right devices to start recording events. I also had to make some adjustments to my xorg.conf file, following some instructions here: https://lists.freebsd.org/pipermail/freebsd-current/2017-April/065653.html This leads to a working config block for the Touchpad: Section "InputDevice" Identifier "Touchpad0" Driver "libinput" Option "Device" "/dev/input/event3" Option "AccelProfile" "adaptive" Option "DisableWhileTyping" "True" Option "MiddleEmulation" "True" Option "ScrollMethod" "edge" Option "Tapping" "True" Option "TappingDrag" "True" Option "TappingDragLock" "False" EndSection However, a small bug has manifested itself w/ security implications. I am noticing that when I type my username and password into the login fields on slim, that input is apparently being echoed to the virtual terminal that slim is running on. This is invisible, however, until you kill X or logout. For a brief second, when slim is restarting, both the username and password are visible in plaintext on the console. Once slim starts up, they can't be seen again. I suspect this laptop being from ~2011 and a bit slow enhances the delay in slim's restart, allowing one to actually glimpse the echo'ed text. I don't recall seeing this when I was using kbd and /dev/psm0 under 12.0-RELEASE.
(In reply to Joshua Kinard from comment #2) For the password echo thing, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220562 (or switch to wayland :P)
(In reply to Greg V from comment #3) Ah ha, well, if that's what the issue is, I can fix that by just using libinput for the mouse/touchpad and then reinstall xf86-input-keyboard and use kbdmux for the keyboard driver. Thanks for the pointer! And I am running Mate, so don't think wayland plays nice with that.
I believe an update that appeared late in the 12.1-RC2 cycle, possibly in a rebuilt binpkg, apparently resolved this issue. I last used the laptop a few months ago with no real problems. I'll file a new bug if the issue pops up again.