On 11-12-01 12:15 AM, Dmitry Torokhov wrote: > On Wed, Nov 30, 2011 at 10:18:10AM -0500, Daniel Manrique wrote: >> On 11-11-29 07:17 PM, Dmitry Torokhov wrote: >>> On Tue, Nov 29, 2011 at 02:43:35PM -0500, Daniel Manrique wrote: >>>> On 11-11-29 12:53 PM, Dmitry Torokhov wrote: >>>>> Hi Daniel, >>>>> >>>>> On Tue, Nov 29, 2011 at 11:26:19AM -0500, Daniel Manrique wrote: >>>>>> Hello, >>>>>> >>>>>> I apologize for sending this bug report directly; with the kernel.org bugtracker >>>>>> down I was told this was the best option for the time being. If this is not >>>>>> correct, could you please let me know of a good place to submit this bug report? >>>>>> >>>>>> I have several Dell laptops with Synaptics touchpads, particularly a group of >>>>>> Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad >>>>>> (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse. >>>>>> >>>>>> This was first reported on kernel 2.6.38, although I think the issue has been >>>>>> present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38 >>>>>> kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well >>>>>> as a "mainline" 3.1.0-rc10 kernel. >>>>>> >>>>>> Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker. >>>>>> The first report I can find is this one: >>>>>> >>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267 >>>>>> >>>>>> This includes a series of log messages I don't see on my systems. I then filed >>>>>> this other bug: >>>>>> >>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650 >>>>>> >>>>>> The last one contains specific information from one of my systems (a Vostro V13). >>>>>> >>>>>> I'd really appreciate any help or guidance on how to solve this problem. If you >>>>>> need me to collect any information or run any tests on these machines, please >>>>>> don't hesitate to ask, these systems are primarily used for testing. >>>>>> >>>>> >>>>> Please do: >>>>> >>>>> - enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug) >>>>> - rmmod psmouse; >>>>> - suspend/resume; >>>>> - collect dmesg; >>>>> - suspend/resume; >>>>> - collect dmesg again >>>>> >>>>> and we'll have to try and find what we do differently. >>>>> >>>>> Thanks. >>>>> >>>> >>>> Hi Dmitry, >>>> >>>> Thanks so much for the quick reply! >>>> >>>> I just ran the tests you requested with some extra steps which I hope won't >>>> confuse things. Here's the sequence I followed: >>>> >>>> - Enabled i8042 debug >>>> - sudo rmmod psmouse. Touchpad of course becomes unresponsive. >>>> - sudo pm-suspend >>>> - Wake the machine by pressing power >>>> - At this point touchpad is unresponsive. >>>> - Collected dmesg-1.txt >>>> - sudo pm-suspend >>>> - wake the machine by pressing power >>>> - At this point touchpad is still unresponsive. >>>> - Collected dmesg-2.txt >>>> - sudo modprobe psmouse. Touchpad begins responding. >>>> - Collected dmesg-3.txt >>>> - sudo pm-suspend >>>> - wake the machine by pressing power >>>> - At this point touchpad is again unresponsive. >>>> - Collected dmesg-4.txt >>>> >>>> To avoid attaching largish files to this email, I put the logs on a >>>> publically-accessible http server at: >>>> http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer >>>> something else. >>>> >>> >>> Hmm, it just does not want to admit that it is synaptics after reset. >>> Does the patch below help any? >> >> Hi Dmitry, >> >> I applied the patch to a 3.2-series kernel (based off 3.2-rc3 I think). It >> applied cleanly to psmouse.c, and after compiling the driver and putting it in >> place of the old psmouse.ko, the touchpad works after resuming from suspend! >> >> I did a comparison test by swapping drivers (old vs. new) without rebooting, by >> rmmodding the existing psmouse driver, putting the old/new file in place, >> reloading the driver and doing a suspend/resume cycle. Consistently, with the >> old/original driver I still see the problem, but with the new/patched driver the >> touchpad is always enabled after resume. >> >> i only tested this on one of the failing Vostro V13, please let me know if I >> should test for anything like possible misbehaviors on other previously-working >> systems or some other kind of regression. >> >> But still, this patch seems to work fine, thanks for this! What's the next step >> for getting this fix into the official kernel? Anything I can do to help? >> > > Could you please try removing either ssleep(1) or querying of device ID > from the patch and see which one of them actually fixes the issue? Hi Dmitry, Certainly! I compiled and tested two new versions of the module, one with the "delaying after reset" code commented out, the other with the "querying ID" block commented out. The ssleep(1); line is what appears to do the trick; the version that just queries the ID exhibits the same problem I reported initially, while the one that just ssleeps works fine, with the touchpad working OK after resuming. I'll await further instructions on this, thanks so much for your help! - Daniel > Thanks! > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
