Hey, That xinput bug sounds brutal. Audio stuttering and infinitely repeating keys just from toggling a mouse device definitely sounds like an interrupt storm or an Xorg locking issue. Given that mess, hitting the pms driver directly with your sysctl workaround was absolutely the right call. The fact that it leaves standard external mice alone is a huge bonus, too.
Regarding the suid helper, you hit the nail on the head—that's exactly what I meant. It's just basic privilege separation. X11 event-parsing code can sometimes be tricky, and if a vulnerability is ever found in the X libraries or your parsing logic, you don't want that process running as root. If you split them, your main daemon runs as your normal user. When it detects typing, it executes a tiny, separate binary (the helper). That helper is the only file you chmod u+s, and its only job is to flip the sysctl values. There's not much literature needed—you'd basically just have two binaries in your Makefile. Even if someone maliciously triggers the helper, the absolute worst they can do is turn your trackpad on and off, which practically eliminates the attack surface. I completely agree about upstreaming a proper toggle. Having something clean like hw.synaptics.disable=1 in the kernel would be vastly superior to relying on the finger_high trick long-term. It might be worth dropping a quick message to the tech-kern or tech-x11 mailing lists describing your daemon and suggesting the boolean switch. The kernel devs are usually pretty receptive to practical quality-of-life fixes like that. Thanks again for putting this together. It's a great tool. Cheers, Aryabhata On Tue, 26 May, 2026, 9:06 pm thezerobit, <[email protected]> wrote: > Thanks, > > The way I handle the permissions is just to `chown root` and `chmod u+s` > the binary. I have a line that runs it in daemon mode at the top of my > ~/.xinitrc file for convenience. The sysctl variable name and values it > can be set to are hard-coded. I could split the sysctl calls into a > separate binary to minimize attack surface area, making a guess at your > reference to a "suid helper". Any examples or literature on the topic > you might know about would be helpful, if there's more to it than just > that. I'm a programmer, but I generally don't write code that runs as > root or do much system administration, so my knowledge in the area is > rudimentary. > > Yes, initially I had experimented with disabling the /dev/wsmouse device > using xinput, but that is buggy, unfortunately. When reenabling the > device, it causes audio playback to stutter for a moment and it causes > keyboard input issues, like the return key will start repeating > endlessly until I hit it again (at least on NetBSD 11 RC3 and RC4). You > have to `enable` the device 2 times to get things back to a normal > working state. Obviously, the daemon is going to be disabling/reenabling > the device constantly, so that's not really workable. I didn't find > anything in wsconsctl, wsconsio.h or manual pages related to wscons that > I could use to disable the trackpad. It was in the `pms` man page that I > found a sysctl variable that would do the trick. Since it is a the > trackpad level, it only disables trackpads, not mice, which is > convenient. If people thought this was useful enough to go into NetBSD > proper, it might be good to have a generic enable/disable switch > (whether a sysctl variable or something else) for trackpads rather than > relying on the finger_high trick. > > -thezerobit > > On 05/26/2026 12:55 am, Aryabhata wrote: > > Hey, > > > > Thanks for sharing this! Dealing with palm-press trackpad jumps on a > > ThinkPad is incredibly annoying, so this is definitely a welcome for > > anyone running NetBSD on a laptop. > > > > The finger_high sysctl trick is a pretty clever workaround to bypass > > the driver interpretation entirely. One quick question on how you're > > handling it: since writing to sysctl knobs usually requires root, does > > the daemon have to run with elevated privileges? Running an X-centric > > tool as root can be a bit sketchy security-wise, so I'm curious if > > you've looked into separating the X11 listener from the actual sysctl > > call, or using a small suid helper. > > > > Also, out of curiosity, did you run into issues trying to use > > user-space tools like xinput or wsconsctl to toggle the device? I know > > if you're using the generic wscons driver it tends to multiplex > > everything into one stream, which makes isolating just the trackpad a > > massive pain—assuming that's why you went the kernel route. > > > > Either way, nice work getting this up. > > > > Cheers, > > > > Aryabhata > > > > On Tue, 26 May, 2026, 3:43 am thezerobit, <[email protected]> > > wrote: > > > >> Hi, > >> I hacked syndaemon to work on NetBSD. Codeberg page: > >> https://codeberg.org/thezerobit/syndaemon-netbsd [1] . Direct > >> download: > >> https://codeberg.org/thezerobit/syndaemon-netbsd/archive/main.tar.gz > >> [2] > >> > >> If you don't know what syndaemon is, it's a little daemon that pays > >> > >> attention to keyboard activity in X and disables the trackpad while > >> you > >> are typing. This is to prevent unintentional mouse movements and > >> clicks > >> on laptop trackpads located just below the keyboard. This is pretty > >> much > >> essential when working on my Thinkpad T580. There is a README.txt > >> in the > >> repo which explains how to compile and use the tool. > >> > >> The reason this is a bit of a hack is that the only way to safely > >> disable the trackpad that I could find was to set the sysctl > >> variable > >> "hw.synaptics.finger_high" to a high enough value that the driver > >> no > >> longer registers interaction. Feel free to contact me directly with > >> > >> feedback or suggestions on how to improve it or if you need help > >> getting > >> it working. > >> > >> -thezerobit > > > > > > Links: > > ------ > > [1] https://codeberg.org/thezerobit/syndaemon-netbsd > > [2] > > https://codeberg.org/thezerobit/syndaemon-netbsd/archive/main.tar.gz >
