Typing causes cursor to stick

Thanks for your report.

Confirmed in Oneiric. The workaround is to disable 'Disable Touchpad while typing' in the touchpad preferences (run 'gnome-control-center mouse', and select tab 'Touchpad' )

Forgot to add some extra info yesterday that this happens both in Unity 2D and 3D so is likely an Xorg problem.

The X stack is working as expected; gnome-settings-daemon is disabling the touchpad while typing, and then re-enabling it after a couple of seconds inactivity.

Moving to gnome-control-center where this behaviour is controlled. We might want to change the default if this is sufficiently objectionable.

This could be considered low importance if the setting that triggers it wasn't default. Try using a laptop with a touchpad with this problem and tell me if it's still Low importance for being fixed... A lot of people who usually use their laptop with only the touchpad will not be happy and won't know how to fix this either.

This is a major usability issue and this bug renders the touchpad nearly unusable with a very poor user experience.
Setting back to high.

Before, in gnome 2.32, how did it work? (sorry, don't have any 2.32 installation to test). I don't see as a very important issue really, as it's worst to have the touchpad being active and moved by mistake while typing.

So, we could set the gsettings to be FALSE by default, but I'm sure it will piss off more people than this issue, that is easily solvable by changing the setting in the mouse & touchpad control center panel

The way it used to work is that the touchpad was locked *while* typing (by default) and moving the cursor with the touchpad after you finished typing would typically not include any delay. What has changed is that gnome-settings-daemon doesn't even think about taking the lock off until you *try to move the cursor*, thus the feeling of the cursor being 'stuck'. It is not acceptable to depend on users applying the 'workaround' (turning locking of the touchpad off) because it would have to applied by *everyone wanting to use the touchpad on the laptop*.

Since it worked fine in Gnome 2.32 as described there should be no excuses about how it can be worked around (a work around is one thing when the odd user here and there needs to apply it and another thing entirely when everyone does.)

I think in terms of fixing this it would be worth investigating why gnome-settings-daemon doesn't contemplate releasing the lock until the user tries to move the cursor after typing.

Just uploaded a package to the ubuntu-desktop PPA:

https://launchpad.net/~ubuntu-desktop/+archive/ppa

so it should be available there in a little bit

So, the 2 seconds delay is on purpose, because it breaks this feature for other people. So the real solution to this bug is to get the synaptics (on xorg and kernel input mailing lists) patches merged in so that palm detection works properly and we can remove the code altogether

@rodrigo, care to provide pointers to the patches you want?

@Rodrigo: palm detection will never be 100% reliable with every touchpad driver and/or hardware. Please do not remove the "Disable touchpad while typing".

Have a look at the related bug 240738 and my comment 27 about Elantech touchpads.

Oliver, we're not removing that setting. I uploaded a g-s-d patch to decrease the delay for syndaemon, from 2 seconds, the default one, to 0.5s. But I was told that would break it for other users, and that there were some patches in the xorg and kernel mailing lists (sorry Bryce, don't have those pointers) to fix the underlying problem.

So I reverted the 0.5s decrease patch, which really didn't fix anything, since the problem seems to be lower in the stack. I guess syndaemon should the responsible for dealing with this correctly? gnome-settings-daemon just calls syndaemon, and uses the explicit 2.0 seconds delay (which is the default in syndaemon), as I was told, to fix other issues. So, should we really keep the 0.5s decrease patch or fix it better in syndaemon or xorg/kernel?

Seems logical to keep the 0.5s decrease patch as a workaround until the proper underlying patches are identified.

I suppose they'll eventually bubble up in future releases of things, so you could leave the workaround in place for oneiric with plan to test reverting it in oneiric+1 to see if it's still needed.

The workaround introduces new bugs, so not sure it's worth re-adding it

This is very bad... it wasn't noticeable at the .5 second delay, and helped alot! In fact, it's one of my favorite features of GNOME, but if this isn't changed.. I'm going to be mad.

This bug was fixed in the package gnome-settings-daemon - 3.1.5-0ubuntu3

---------------
gnome-settings-daemon (3.1.5-0ubuntu3) oneiric; urgency=low

  * debian/gnome-settings-daemon.gsettings-override:
    - Enable GConf bridge plugin by default
  * debian/patches/10_smaller_syndaemon_timeout.patch:
    - Use a smaller timeout for syndaemon (LP: #801763)
 -- Rodrigo Moya <email address hidden> Mon, 22 Aug 2011 10:46:19 +0200

Hi,

By reducing the upstream default 2 sec timout, this fix introduces a severe usability issue for macbook pro users like me. See lp #962958.

Getting to your original bug:

"1.) Type a few key strokes.
2.) Try to move the cursor using the touchpad."

That issue can be easily fixed by adding -t option to syndaemon launch without changing the default timeout. -t option ensures the mouse is movable during the timeout, but will prevent any accidental clicks. So, if you are worried about mouse movement only during that 2 sec, this is better way to patch.

Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=673055