ubuntu-x-swat team mailing list archive

[Bryce Harrington <774978@xxxxxxxxxxxxxxxxxx>]

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

** Bug watch added: Debian Bug tracker #598834
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598834

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-input-synaptics in Ubuntu.
https://bugs.launchpad.net/bugs/774978

Title:
  xserver crashes in RecordAReply when XRecord is enabled in syndaemon