Comment 6 for bug 1834113

Revision history for this message
Bryce Harrington (bryce) wrote :

touchpad issues with power management can be challenging to sort out, and it's not unusual for them to reproduce non-reliably. Power management problems are almost always kernel-related, though I know it can be labor intensive to test.

However, I've seen the double-action behavior myself with touchpads and keyboards, and the problem wasn't the kernel; in at least one of those cases the cause was a second package that was consuming input events, which resolved through a combination of apt-get purges and reboots. Reviewing the tail end of /var/log/apt/history.log and rolling things back one by one might reveal something, but you'd need to do multiple suspend/resume cycles to test each time. You mentioned seeing this behavior starting a couple days ago, so you could focus attention on changes within the past week or so. (And check when the qemu 1:3.1+dfsg-2ubuntu3.1 update installed (and when you subsequently rebooted)).

An alternative thing to test would be to see if there are differences in what processes are running when the bug is reproducing, vs. when it is not. You'd want to examine the process tables on both the host and guest. But its possible something starts stealing events after resume, that wasn't doing so before, and diffing process tables won't show that; instead, the way to diagnose this would be to kill X clients one by one (e.g. `xlsclients -la`).

Beyond that, I can just offer some of the standard troubleshooting techniques for input device troubles:

  * Check if your bios firmware is up to date
  * Identify your touchpad device and driver (xinput / sudo lsinput / sudo lshw -C input)
  * Check input device properties if using evdev/synaptics (i.e. have any settings changed?)
  * xev is a helpful testing tool
  * Good luck