[intrepid] touch pad speed reset when return from suspend

[shockawe5]

Description: Ubuntu intrepid (development branch)
Release: 8.10

Using the beta release of Ubuntu Intrepid Ibex 8.10. When I boot the computer, my touchpad speed that I initially set works fine. However, when I suspend the laptop, and then resume, the touchpad speed is set back to default (really slow). Restarting X with ctrl+alt+backspace fixes the problem.

The touchpad speed upon resuming from suspend should be consistent with what it is when the system is cold booted. Configurations should not be lost when the system resumes from suspend.

[J. Bruce Fields (bfields-fieldses)]

I get the same thing on Intrepid with a Dell 1420n. Other touchpad settings are also lost. (E.g. tapping on the touchpad produces a mouse click after suspend/resume, though I have that turned off.)

[J. Bruce Fields (bfields-fieldses)]

(ALso note this was fine under Hardy, so this is a regression.)

[William Grant (wgrant)]

Please try gnome-settings-daemon from my PPA - it should fix this.

[J. Bruce Fields (bfields-fieldses)]

I installed 2.24.0-0ubuntu4~wgrant1, rebooted for good measure, then tried a suspend/resume. Behavior is unchanged--I still end up with different touchpad behavior after resume.

I also get a "Unable to start the settings manager 'gnome-settings-daemon'" error after trying to set preferences after resume.

[William Grant (wgrant)]

Well, that would be the problem. Run gnome-setting-daemon in a terminal after resume, and see what error you get, or check ~/.xsession-errors.

[J. Bruce Fields (bfields-fieldses)]

Sorry for the delay. xsession-errors attached. I have gnome-settings-daemon 2.2.4.0-0ubuntu3.1 installed, but it's dying after resume. If I run it from a terminal it starts sucesfully and I see no error output.

[J. Bruce Fields (bfields-fieldses)]

Hm, no actually I was wrong, it's not crashing--it's just using, according to top, 20% cpu and 22% memory (on a laptop with 4g installed), and (I assume) failing to respond to anyone, since the various properties dialogs take a long time to come up, then eventually give the "unable to start settings manager gnome-settings-daemon" error when they do.

This happens after a gnome-settings-daemon has been running an hour or two, without the need for any suspend/resume.

Apologies, this is probably the wrong bug to be commenting on at this point!

[William Grant (wgrant)]

There have been a few iterations of my package since then. ~wgrant5 will be there in perhaps 25 minutes. Can you test that?

[William Grant (wgrant)]

Actually, i386 is already there now.

[J. Bruce Fields (bfields-fieldses)]

Yep, I installed wgrant5, rebooted, and saw no change in behavior. Actually I suppose what I'm seeing now is #294501, so I should add a comment there.

[J. Bruce Fields (bfields-fieldses)]

With ~wgrant6, this problem is now really fixed for me, thanks!!!

[Martin-Éric Racine (q-funk)]

On Fri, Nov 7, 2008 at 8:22 PM, J. Bruce Fields wrote:
> With ~wgrant6, this problem is now really fixed for me, thanks!!!

Unless, I'm dreaming, this one indeed seems to fix both the touchpad's
horizontal scrolling and the left-handed mouse buttons. Good work!
Just out of curiosity, what was the solution?

[William Grant (wgrant)]

The problem was dodgy X input devices in xorg.conf - in particular, tablet entries without the corresponding serial device actually existing.

The touchpad setting code in gnome-settings-daemon looked for DevicePresence notifications, and checked if they were of the DeviceAdded type. If they were, it proceeded to reconfigure all input devices. Setting the touchpad properties requires opening each device, and checking if it has the right properties. When X sees a device open request for the non-existent tablet, it revives the X device to look for the serial device, which triggers another DeviceAdded event. g-s-d notices this. Rinse. Repeat. Chaos ensues.

The fix for this was to dig through the xserver code and work out that I should be looking for DeviceEnabled rather than DeviceAdded. The device for the missing tablet never finishes initialising, so never fires a DeviceEnabled.

Since the Synaptics touchpad driver now reports itself as being of type XI_TOUCHPAD rather than XI_MOUSE, I also added further checks to not even bother opening a device if it isn't an XI_TOUCHPAD.

[Martin-Éric Racine (q-funk)]

On Sat, Nov 8, 2008 at 2:19 AM, William Grant wrote:
> The fix for this was to dig through the xserver code and work out that I
> should be looking for DeviceEnabled rather than DeviceAdded. The device
> for the missing tablet never finishes initialising, so never fires a
> DeviceEnabled.

Was the mouse code also upgraded to watch for DeviceEnabled instead of
DeviceAdded?

--
Best Regards,
Martin-Éric

[William Grant (wgrant)]

Yes, that's what I meant here:

"The fix for this was to dig through the xserver code and work out that I should be looking for DeviceEnabled rather than DeviceAdded."