"Disable while typing" should disable cursor movement

[Jason Gerard DeRose]

On a modern laptop with a large touchpad/clickpad, your palms tend to brush the touch surface as you type. The problem is that on Ubuntu, this creates an annoying amount of cursor wiggle. Competing platforms don't have this problem, so this needs to be improved on Ubuntu.

Part of the problem is that `xserver-xorg-input-synaptics` driver doesn't do effective palm detection (it seems), and part of the problem is that `gnome-settings-daemon` launches `syndaemon` such that it *never* disables cursor movement.

Currently syndaemon is launched like this:

  syndaemon -i 1.0 -t -K -R

The "-t" option tells syndaemon to never block cursor movement. It will only block accidental vertical scrolling (which is darn near impossible to do on a modern system with two finger scrolling), and block accidental tap-to-click (which seems unlikely something you can do by mistake with your palms). So from a user perspective, "Disable while typing" currently does nothing.

I'm proposing that syndaemon instead be launched like this:

  syndaemon -i 0.5 -K -R

Without the "-t" option, syndaemon will block cursor movement, vertical scrolling, and tap-to-click. And the "-i 0.5" means it will block it for 500ms (half a second).

System76 has been shipping a patched `gnome-settings-daemon` (Raring) on all our products for the last two months, and we've received no support issues about it (if this caused noticeable usability issues, I'm confident we'd have heard about it).

We've also done a lot of testing and tuning on the timeout threshold, and 500ms seems like about the sweet spot. It's long enough to be decently effective for most typists, but not so long that the user will catch the trackpad still disabled when they move from typing back to "cursoring" :P

Note that this isn't a prefect solution, and you really can't do this especially well with a static timeout anyway (would be better to be dynamic based on typing speed). For slow typists, 500ms often isn't long enough. But for now, I feel it's better to find that sweet spot where it at least gives some improvement for most users, without causing any negative impact for any users.

I have a Saucy package available for testing here:
https://launchpad.net/~system76-dev/+archive/daily?field.series_filter=saucy

And the proposed branch here:
https://code.launchpad.net/~jderose/ubuntu/saucy/gnome-settings-daemon/tune-syndaemon2

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-settings-daemon 3.6.4-0ubuntu16
ProcVersionSignature: Ubuntu 3.11.0-3.7-generic 3.11.0-rc6
Uname: Linux 3.11.0-3-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.1-0ubuntu2
Architecture: amd64
Date: Thu Aug 22 07:35:33 2013
MarkForUpload: True
SourcePackage: gnome-settings-daemon
UpgradeStatus: No upgrade log present (probably fresh install)

[Jason Gerard DeRose (jderose)]

Note that the diff is mostly UDD accounting in the .pc directory, but the actual patch is tiny:

http://bazaar.launchpad.net/~jderose/ubuntu/saucy/gnome-settings-daemon/tune-syndaemon2/view/head:/debian/patches/tune-syndaemon.patch

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alberto Salvia Novella (es20490446e)]

This bug needs now to be notified to the upstream developers of GNOME (https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding_upstream).

Once this has been done, it will be ready to be worked on by a developer.

[Sebastien Bacher (seb128)]

Sorry for not commenting on that earlier...

Just as a comment, I don't know how you are doing your user testing but from what we see in Ubuntu/on launchpad, the current settings are working quite nicely. We tried quite some different behaviour, timing, options in the past and we always had some slashback/unhappy users. We didn't really get any complain from the current configuration though. Is the feedback one you got from your users/customers or is that just the feeling from the system76 team looking at the polish of the OS?

> The problem is that on Ubuntu, this creates an annoying amount of cursor wiggle. Competing platforms don't have this problem,
> so this needs to be improved on Ubuntu.

what are competing platforms doing? blocking the cursor move?

> block accidental tap-to-click (which seems unlikely something you can do by mistake with your palms).

not sure what makes you think it's "unlikely", before we added that syncdaemon use it was trivial to miss-click by holding your hands over the touchpad area, some touchpads are just weird acting.

see e.g https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/240738 and the duplicates/comment

> Without the "-t" option, syndaemon will block cursor movement,

right, that's wrong, we have been there, see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/801763

blocking movement feels wrong, you type than move to the touchpad and try to move the cursor and it doesn't react, that's a very confusing/frustrating user experience

> 500ms seems like about the sweet spot

0.5 was creating issues for some users, see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/962958

[Jason Gerard DeRose (jderose)]

Sebastian,

Our initial testing and tuning was among co-workers, friends, family that we could test on.

So far we haven't gotten any complaints from customers about the 0.5 second delay being too long, although some customers still complain that they don't feel "Disable while typing" does what it should. So I'm thinking we should try just a touch longer, maybe 0.6 seconds.

As far as competing platforms, I know OSX does disable the trackpad briefly after any typing activity. The also do palm detection, but how effective that is varies a lot by hardware. It doesn't work very well on current System76 products because the trackpad isn't centered beneath home row.

Note that with my proposed settings, syndaemon does still does disable accidental tap to click. I was just commenting that from my experience an System76 hardware anyway, I wasn't getting accidental tap to clicks when I turned off sysdaemon entirely (and turned tap to click on, which I normally turn off). But obviously that's very hardware specific.