> ... and the trackpads on PCs all still suck at palm rejection and responsiveness while typing. FWIW: this is not a hardware problem. This is an issue with tr

> ... and the trackpads on PCs all still suck at palm rejection and responsiveness while typing. FWIW: this is not a hardware problem. This is an issue with trackpad drivers on PCs, which have been shit since the dawn of time. I'm typing this from a MacBook Pro running Arch. It took me quite some time to configure the trackpad so that it was comfortable and half-usable. There's a driver for X called "mtrack"[1] which handles clickpads (i.e, where the entire trackpad surface is a button) properly. It's a more configurable fork of the "multitouch" driver that comes with most popular Linux distros these days. It does tap-to-click, tap and drag, drag lock and multitouch just fine. mtrack's palm detection is better than most trackpad drivers, but still not perfect, which is why I ended up having to turn off tap-to-click entirely because I'd get accidental mouse input while typing even with the trackpad sensitivity turned way down. Now my trackpad works great. I still can't use guestures, though, because (1) X has shitty guesture support and (2) the GNOME folks haven't yet added guestures to Shell. The situation will (hopefully) be fixed with a future release of X and GNOME. I did get some guestures working using an unholy combination of xbindkeys, xdo and a Python script, but it wasn't worth it. If you're running Windows on your MacBook and using Apple's drivers, you're fine. OTOH, if you're using a non-Apple notebook running Windows and your trackpad vendor doesn't give a fuck about writing good drivers, you're totally and utterly screwed. This same trackpad works flawlessly on OS X. Clearly, the folks at Apple have spent a lot of time analyzing trackpad input patterns and determined the types of input that should be ignored. [1] https://github.com/BlueDragonX/xf86-input-mtrack https://github.com/BlueDragonX/xf86-input-mtrack