I root-caused this bug to figure out what exactly went wrong here, also to help understand the ramifications of dropping xrecord.

Back in October last year, bug #598834 was filed in Debian[1] requesting that  libxtst-dev be added as a dependency to xserver-xorg-input-synaptics, to enable syndaemon's -R option to work.  The man page documents this option as:

  Use the XRecord extension for detecting keyboard activity instead of polling the keyboard state.

XRecord has kind of a mixed history and I even recall an X.org conference where it was considered to drop it[2] since it's not been too well maintained.  Likely it's a bit buggy.  But not a big deal; we didn't use -R for syndaemon in Ubuntu, but this would make the functionality available to anyone wishing to opt in to use it for testing or whatever.  We didn't even take note of the new option.

But then one day, someone noticed that syndaemon was eating precious battery power due to polling and noticed it had this -R option which promised to make it stop doing it.  Polling is bad.  And so it was that on April 5th, gnome-settings-daemon opted to start calling syndaemon with the -R flag when people have the "Disable touchpad while typing" option flipped on.

Bug #754470[3] was filed shortly thereafter, on April 8th.  It seemed that people were suddenly seeing syndaemon consuming 100% CPU either right after boot or some various point during use.  Gah!  Us X guys got a spate of these reports around this time, which was quite troubling because it was so near to release and (as far as we knew) we hadn't made any changes to X that would have caused this!

Chase Douglas was quite a hero and jumped right on the problem.  He had been doing a lot of X development work for touch devices which had involved a number of uploads to -synaptics, and so he was both familiar with the code and perhaps worried his changes might have caused the problem people were seeing.  He figured out that XRecord wasn't able to process all the different types of events that it was experiencing, and so would leave some events on the stack and get stuck in a loop trying to reprocess them.  He added a patch that would work around this problem by just draining those unrecognized events.  The CPU issue was solved.  But everyone knew this was just papering over whatever the underlying problem was.  His fix was uploaded 04-16.

Bug #771655[4] was filed on 4/26 suggesting a regression occurred starting around apr 20th.  This bug #774978[5] was filed on 5/1.  Quickly we started seeing a deluge of dupe bug reports about this X crash.  (Check it: dozens of dupes and 37 affected; plus 28 on #760695, 15 on #776654, 22 on #780358, and 80! on #778490.)

On 5/23 Sarvatt figured out that disabling record made the problem go away.  I'd really like to know how he had this brainstorm, and wish we'd pumped the fix out sooner after that point.  Sarvatt kicks ass, we need to listen to him better.  Anyway, subsequent testers on this bug confirm his findings, and here we are now today.

1:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598834
2:  http://xorg.freedesktop.org/wiki/Events/XDC2008/Notes
3:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/754470
4:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/771655
5:  https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/774978