* [PATCH] Reset ps/2 port should psmouse_probe fail before retrying @ 2010-04-16 22:52 Peter M. Petrakis 2010-04-17 11:01 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-16 22:52 UTC (permalink / raw) To: linux-input; +Cc: rubini Hi All, I filed a bug on this too: https://bugzilla.kernel.org/show_bug.cgi?id=15780 This particular laptop will lose it's synaptics touch pad on return from suspend state. Reloading the psmouse module makes no difference. I came up with the attached work around which simply calls psmouse_reset on the port should the initial probe fail. This solves the problem for me and I've tested this on several laptops. Initially discovered on Ubuntu 2.6.31 (karmic) and the problem continues to exist in lucid 2.6.32. I've filed a bug against ubuntu kernel here: https://bugs.launchpad.net/oem-priority/+bug/551234 though the Ubuntu kernel team would really like to get upstream's input on the matter before accepting the patch. Please let me know what you think. Thanks. Peter -- From e997195a6488753738523b92cbcc97cb2f4bda03 Mon Sep 17 00:00:00 2001 From: Peter M. Petrakis <peter.petrakis@canonical.com> Date: Fri, 16 Apr 2010 17:56:24 -0400 Subject: [PATCH] Reset the PS/2 port should psmouse_probe fail for any reason. This is necessary for some PS/2 devices who can't even be identified when returning from sleep (S3). --- drivers/input/mouse/psmouse-base.c | 29 ++++++++++++++++++++++++++--- 1 files changed, 26 insertions(+), 3 deletions(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index d8c0c8d..a51b9a7 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -905,12 +905,12 @@ static const struct psmouse_protocol *psmouse_protocol_by_name(const char *name, return NULL; } - /* - * psmouse_probe() probes for a PS/2 mouse. + * __psmouse_probe() probes for a PS/2 mouse. + * Wrapped by psmouse_probe() for clean reset code. */ -static int psmouse_probe(struct psmouse *psmouse) +static int __psmouse_probe(struct psmouse *psmouse) { struct ps2dev *ps2dev = &psmouse->ps2dev; unsigned char param[2]; @@ -941,6 +941,29 @@ static int psmouse_probe(struct psmouse *psmouse) } /* + * Wrapper for probe routine to cleanly reset the device should + * the initial probe fail for any reason. + */ +static int psmouse_probe(struct psmouse *psmouse) +{ + struct ps2dev *ps2dev = &psmouse->ps2dev; + int i; + int ret = -1; + + for (i=0; i < 3; i++) { + ret = __psmouse_probe(psmouse); + if (ret == 0) + break; + + printk(KERN_ERR "psmouse.c: Error encountered while probing " + "PS/2 device on %s, resetting\n", ps2dev->serio->phys); + psmouse_reset(psmouse); + } + + return ret; +} + +/* * Here we set the mouse resolution. */ -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-16 22:52 [PATCH] Reset ps/2 port should psmouse_probe fail before retrying Peter M. Petrakis @ 2010-04-17 11:01 ` Christoph Fritz 2010-04-17 15:31 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-17 11:01 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: linux-input, rubini Am Freitag, den 16.04.2010, 18:52 -0400 schrieb Peter M. Petrakis: > I filed a bug on this too: > > https://bugzilla.kernel.org/show_bug.cgi?id=15780 > > This particular laptop will lose it's synaptics touch > pad on return from suspend state. > I came up with the attached work around which simply calls > psmouse_reset on the port should the initial probe fail. In i8042.c i8042_controller_selftest() gets also called after suspending: So give it a try and add "i8042.reset=1" to your kernel-parameters. If that works for you, add your device to the i8042_dmi_reset_table in i8042-x86ia64io.h or tell us the output of: cat /sys/class/dmi/id/product_name cat /sys/class/dmi/id/sys_vendor ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-17 11:01 ` Christoph Fritz @ 2010-04-17 15:31 ` Peter M. Petrakis 2010-04-17 16:53 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-17 15:31 UTC (permalink / raw) To: Christoph Fritz; +Cc: linux-input, rubini Hi, i8042.reset=1 was one the first things we tried and it didn't improve the situation. Now looking at the code for i8042_controller_reset, I don't recall seeing these printks though I could double check. Any other suggestions for resets or instrumentation? Thanks. Peter On 04/17/2010 07:01 AM, Christoph Fritz wrote: > Am Freitag, den 16.04.2010, 18:52 -0400 schrieb Peter M. Petrakis: >> I filed a bug on this too: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=15780 >> >> This particular laptop will lose it's synaptics touch >> pad on return from suspend state. > >> I came up with the attached work around which simply calls >> psmouse_reset on the port should the initial probe fail. > > In i8042.c i8042_controller_selftest() gets also called after > suspending: So give it a try and add "i8042.reset=1" to your > kernel-parameters. If that works for you, add your device to the > i8042_dmi_reset_table in i8042-x86ia64io.h or tell us the output > of: > cat /sys/class/dmi/id/product_name > cat /sys/class/dmi/id/sys_vendor > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-17 15:31 ` Peter M. Petrakis @ 2010-04-17 16:53 ` Christoph Fritz 2010-04-19 15:33 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-17 16:53 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: linux-input, rubini Hi Am Samstag, den 17.04.2010, 11:31 -0400 schrieb Peter M. Petrakis: > Hi, > > i8042.reset=1 was one the first things we tried and it didn't > improve the situation. Now looking at the code for > i8042_controller_reset, I don't recall seeing these printks > though I could double check. And as far as I recall, you should see them. > Any other suggestions for > resets or instrumentation? not really, maybe you can check what windows (without vendor drivers) does ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-17 16:53 ` Christoph Fritz @ 2010-04-19 15:33 ` Peter M. Petrakis 2010-04-20 0:37 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-19 15:33 UTC (permalink / raw) To: Christoph Fritz; +Cc: linux-input, rubini Retesting here and I've found that with i8042.reset=1, i8042_controller_selftest is returning 0. The reason I'm not seeing any messages is because there's nothing to complain about at this level. 202 pm-suspend(6228): -> i8042_controller_selftest i8042_controller_selftest args [] i8042_controller_selftest locals [param=0x0 i=?] 206 pm-suspend(6228): -> i8042_command i8042_command args [param=0xf3715e2f command=0x1aa] i8042_command locals [flags=? retval=?] exit 798 pm-suspend(6228): -> i8042_command i8042_command args [return=0x0] exit 800 pm-suspend(6228): -> i8042_controller_selftest You can see from the triage notes here: https://bugzilla.kernel.org/show_bug.cgi?id=15780 That psmouse can't even identify the device. param[0] = 0xa5; if (ps2_command(ps2dev, param, PSMOUSE_CMD_GETID)) return -1; With regards to windows... What am supposed to be able to find out? Of course it works, but how am I supposed to crack open the driver to find out what it's doing? Thanks. Peter On 04/17/2010 12:53 PM, Christoph Fritz wrote: > Hi > > Am Samstag, den 17.04.2010, 11:31 -0400 schrieb Peter M. Petrakis: >> Hi, >> >> i8042.reset=1 was one the first things we tried and it didn't >> improve the situation. Now looking at the code for >> i8042_controller_reset, I don't recall seeing these printks >> though I could double check. > > And as far as I recall, you should see them. > >> Any other suggestions for >> resets or instrumentation? > > not really, maybe you can check what windows (without vendor drivers) > does > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-19 15:33 ` Peter M. Petrakis @ 2010-04-20 0:37 ` Christoph Fritz 2010-04-20 21:08 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-20 0:37 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: linux-input, rubini Hi Peter, does this work for you? I8042_CMD_AUX_ENABLE gets now triggered during pm_restore. diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c index 6440a8f..1af5a58 100644 --- a/drivers/input/serio/i8042.c +++ b/drivers/input/serio/i8042.c @@ -1151,8 +1151,10 @@ static int i8042_pm_restore(struct device *dev) printk(KERN_WARNING "i8042: failed to resume active multiplexor, " "mouse won't work.\n"); - } else if (i8042_ports[I8042_AUX_PORT_NO].serio) + } else if (i8042_ports[I8042_AUX_PORT_NO].serio) { + i8042_toggle_aux(true); i8042_enable_aux_port(); + } if (i8042_ports[I8042_KBD_PORT_NO].serio) i8042_enable_kbd_port(); ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-20 0:37 ` Christoph Fritz @ 2010-04-20 21:08 ` Peter M. Petrakis 2010-04-21 6:33 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-20 21:08 UTC (permalink / raw) To: Christoph Fritz; +Cc: linux-input, rubini Ugh... I never get out of suspend with this patch, also tried i8042_toggle_aux(false) followed by ... (true) with the same result. Any other ideas? Thanks. Peter On 04/19/2010 08:37 PM, Christoph Fritz wrote: > Hi Peter, > > does this work for you? > > I8042_CMD_AUX_ENABLE gets now triggered during pm_restore. > > diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c > index 6440a8f..1af5a58 100644 > --- a/drivers/input/serio/i8042.c > +++ b/drivers/input/serio/i8042.c > @@ -1151,8 +1151,10 @@ static int i8042_pm_restore(struct device *dev) > printk(KERN_WARNING > "i8042: failed to resume active multiplexor, " > "mouse won't work.\n"); > - } else if (i8042_ports[I8042_AUX_PORT_NO].serio) > + } else if (i8042_ports[I8042_AUX_PORT_NO].serio) { > + i8042_toggle_aux(true); > i8042_enable_aux_port(); > + } > > if (i8042_ports[I8042_KBD_PORT_NO].serio) > i8042_enable_kbd_port(); > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-20 21:08 ` Peter M. Petrakis @ 2010-04-21 6:33 ` Dmitry Torokhov 2010-04-21 16:05 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-21 6:33 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Christoph Fritz, linux-input, rubini On Tue, Apr 20, 2010 at 05:08:28PM -0400, Peter M. Petrakis wrote: > Ugh... I never get out of suspend with this patch, also > tried i8042_toggle_aux(false) followed by ... (true) with the > same result. Any other ideas? Thanks. I think retrying the probe is fine, however it shoudl only be done in resume path, otheriwse you will make people that really do not use PS/2 mice unhappy. BTW, what kind of laptop and touchpad is it? -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-21 6:33 ` Dmitry Torokhov @ 2010-04-21 16:05 ` Peter M. Petrakis 2010-04-21 17:10 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-21 16:05 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Christoph Fritz, linux-input, rubini The laptop is a Dell "yet to be officially released" laptop, the touchpad reports itself as: Apr 21 11:24:05 ubuntu-laptop kernel: [ 983.174813] input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input14 I didn't find any additional attributes in sysfs that could give me the fw revision or model. It doesn't show up in dmidecode either. With regards to retrying the probe... which resume path? psmouse currently doesn't have one. Thanks. Peter On 04/21/2010 02:33 AM, Dmitry Torokhov wrote: > On Tue, Apr 20, 2010 at 05:08:28PM -0400, Peter M. Petrakis wrote: >> Ugh... I never get out of suspend with this patch, also >> tried i8042_toggle_aux(false) followed by ... (true) with the >> same result. Any other ideas? Thanks. > > I think retrying the probe is fine, however it shoudl only be done in > resume path, otheriwse you will make people that really do not use PS/2 > mice unhappy. > > BTW, what kind of laptop and touchpad is it? > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-21 16:05 ` Peter M. Petrakis @ 2010-04-21 17:10 ` Dmitry Torokhov 2010-04-21 19:38 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-21 17:10 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Christoph Fritz, linux-input, rubini On Wed, Apr 21, 2010 at 12:05:55PM -0400, Peter M. Petrakis wrote: > The laptop is a Dell "yet to be officially released" laptop, > the touchpad reports itself as: > > Apr 21 11:24:05 ubuntu-laptop kernel: [ 983.174813] > input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input14 Umm, Synaptics but not using SynPS protocol. Some users will not be happy... Is it after cold boot or resume? Also, is it a multiouch model (does the box have the $OTHER_OS on it)? > > I didn't find any additional attributes in sysfs that could give me > the fw revision or model. It doesn't show up in dmidecode either. > > With regards to retrying the probe... which resume path? psmouse > currently doesn't have one. Thanks. That'd be "reconnect" in serio speak, so you need to look into psmouse_reconnect(). -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-21 17:10 ` Dmitry Torokhov @ 2010-04-21 19:38 ` Peter M. Petrakis 2010-04-21 19:52 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-21 19:38 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Christoph Fritz, linux-input, rubini This issue only occurs on resume, boot is fine. It is indeed a multitouch. It doesn't have the $OTHER_OS installed but it could if necessary. Peter On 04/21/2010 01:10 PM, Dmitry Torokhov wrote: > On Wed, Apr 21, 2010 at 12:05:55PM -0400, Peter M. Petrakis wrote: >> The laptop is a Dell "yet to be officially released" laptop, >> the touchpad reports itself as: >> >> Apr 21 11:24:05 ubuntu-laptop kernel: [ 983.174813] >> input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input14 > > Umm, Synaptics but not using SynPS protocol. Some users will not be > happy... Is it after cold boot or resume? Also, is it a multiouch model > (does the box have the $OTHER_OS on it)? > >> >> I didn't find any additional attributes in sysfs that could give me >> the fw revision or model. It doesn't show up in dmidecode either. >> >> With regards to retrying the probe... which resume path? psmouse >> currently doesn't have one. Thanks. > > > That'd be "reconnect" in serio speak, so you need to look into > psmouse_reconnect(). > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-21 19:38 ` Peter M. Petrakis @ 2010-04-21 19:52 ` Dmitry Torokhov 2010-04-21 21:10 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-21 19:52 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Christoph Fritz, linux-input, rubini On Wed, Apr 21, 2010 at 03:38:59PM -0400, Peter M. Petrakis wrote: > This issue only occurs on resume, boot is fine. It is indeed > a multitouch. Ok, so full multitouch is not supported at the moment but the est of teh features shoudl work. > It doesn't have the $OTHER_OS installed but it > could if necessary. Can you enable i8042 debugging: echo 1 > /sys/module/i8042/parameters/debug and do suspend/resume cycle and share dmesg? I wonder where exactly reconnect fails. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-21 19:52 ` Dmitry Torokhov @ 2010-04-21 21:10 ` Peter M. Petrakis 2010-04-22 16:28 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-21 21:10 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Christoph Fritz, linux-input, rubini [-- Attachment #1: Type: text/plain, Size: 4052 bytes --] Here you are: # suspend prep [ 3069.125781] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 3069.125938] sd 0:0:0:0: [sda] Stopping disk [ 3069.533977] PM: suspend of drv:sd dev:0:0:0:0 complete after 408.513 msecs [ 3069.565486] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: d4 -> i8042 (command) [767816] [ 3069.565652] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: f5 -> i8042 (parameter) [767816] [ 3069.568889] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 1, 12) [767816] [ 3069.568911] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: d4 -> i8042 (command) [767816] [ 3069.569076] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: ff -> i8042 (parameter) [767816] [ 3069.572360] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 1, 12) [767817] [ 3069.941761] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: aa <- i8042 (interrupt, 1, 12) [767910] [ 3069.942864] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, 1, 12) [767910] [ 3069.942884] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: d4 -> i8042 (command) [767910] [ 3069.943050] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [767910] [ 3069.946026] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 1, 12) [767911] [ 3069.946044] PM: suspend of drv:psmouse dev:serio1 complete after 380.858 msecs [ 3069.946053] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [767911] [ 3069.946679] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: fa <- i8042 (interrupt, 0, 1) [767911] [ 3069.946954] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: aa <- i8042 (interrupt, 0, 1) [767911] [ 3070.045080] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 60 -> i8042 (command) [767936] [ 3070.045351] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [767936] [ 3070.045568] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 60 -> i8042 (command) [767936] [ 3070.045785] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 47 -> i8042 (parameter) [767936] [ 3070.045879] ACPI handle has no context! [ 3073.209444] atheros_eth 0000:05:00.0: PCI INT A disabled and we never see psmouse again. This is the first thing we seem from the serial port after resume. [1266874880.096844] iwlagn 0000:04:00.0: RF_KILL bit toggled to enable radio. [1266874880.206849] PM: resume of drv:atheros_eth dev:0000:05:00.0 complete after 110.160 msecs [1266874880.262851] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 60 -> i8042 (command) [769164] [1266874880.263018] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 74 -> i8042 (parameter) [769164] [1266874880.263234] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 60 -> i8042 (command) [769164] [1266874880.263503] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 56 -> i8042 (parameter) [769164] [1266874880.263720] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 60 -> i8042 (command) [769164] [1266874880.263936] /build/buildd/linux-2.6.32/drivers/input/serio/i8042.c: 47 -> i8042 (parameter) [769164] [1266874880.366634] PM: resume of drv:usb dev:1-1 complete after 102.691 msecs [1266874880.406594] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [1266874880.414624] ata5: SATA link down (SStatus 0 SControl 300) Full logs attached. Peter On 04/21/2010 03:52 PM, Dmitry Torokhov wrote: > On Wed, Apr 21, 2010 at 03:38:59PM -0400, Peter M. Petrakis wrote: >> This issue only occurs on resume, boot is fine. It is indeed >> a multitouch. > > Ok, so full multitouch is not supported at the moment but the est of teh > features shoudl work. > >> It doesn't have the $OTHER_OS installed but it >> could if necessary. > > Can you enable i8042 debugging: > > echo 1 > /sys/module/i8042/parameters/debug > > and do suspend/resume cycle and share dmesg? I wonder where exactly > reconnect fails. > > Thanks. > [-- Attachment #2: i8042_debug_resume.log.bz2 --] [-- Type: application/octet-stream, Size: 22191 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-21 21:10 ` Peter M. Petrakis @ 2010-04-22 16:28 ` Christoph Fritz 2010-04-22 21:48 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-22 16:28 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Dmitry Torokhov, linux-input, rubini Hi, to quote 4d368456808c977b8e9782dbe9542cf8ddedbab8 : Input: synaptics - ensure we reset the device on resume When resuming from suspend newer Synaptics touchpads do not recover correctly. Analysis of the resume sequence as applied in Linux was compared to that of other operating systems. This indicated that the other OSs were resetting the mouse before attempting to detect it (for all Synaptics touchpads, old and new). Applying this same modification fixes these newer Synaptics touchpads and brings the driver into line with common OS reset behaviour. <quote end> So Synaptics touchpads which are not not yet covered by their driver need to be resetted when resuming from suspend. But the device we are actually talking about will be sooner or later supported by the synaptics driver, and should all other devices who act normal be resetted too? diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index d8c0c8d..6877371 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -1383,6 +1383,7 @@ static int psmouse_reconnect(struct serio *serio) struct psmouse *parent = NULL; struct serio_driver *drv = serio->drv; int rc = -1; + int retries = 0; if (!drv || !psmouse) { printk(KERN_DEBUG "psmouse: reconnect request, but serio is disconnected, ignoring...\n"); @@ -1401,10 +1402,14 @@ static int psmouse_reconnect(struct serio *serio) if (psmouse->reconnect) { if (psmouse->reconnect(psmouse)) goto out; - } else if (psmouse_probe(psmouse) < 0 || + } else { + while ((retries++ < 3) && psmouse_reset(psmouse)) + /* empty */; + if (psmouse_probe(psmouse) < 0 || psmouse->type != psmouse_extensions(psmouse, psmouse_max_proto, false)) { - goto out; + goto out; + } } /* ok, the device type (and capabilities) match the old one, ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-22 16:28 ` Christoph Fritz @ 2010-04-22 21:48 ` Peter M. Petrakis 2010-04-22 21:55 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-22 21:48 UTC (permalink / raw) To: Christoph Fritz; +Cc: Dmitry Torokhov, linux-input, rubini Hi, This one is a winner. with regards to your follow up. I wouldn't want to reset something unless we have cause to. This code seems to be doing the right thing e.g. I see "unable to query synaptics hardware" followed by it's (re)discovery on return from S3. When it's fully supported by the Synaptics driver, the initial reconnect will succeed and we'll never get to this additional failsafe code which is essentially a catch all for the bleeding edge. Peter On 04/22/2010 12:28 PM, Christoph Fritz wrote: > Hi, > > to quote 4d368456808c977b8e9782dbe9542cf8ddedbab8 : > > Input: synaptics - ensure we reset the device on resume > > When resuming from suspend newer Synaptics touchpads do not recover > correctly. Analysis of the resume sequence as applied in Linux was > compared to that of other operating systems. This indicated that the > other OSs were resetting the mouse before attempting to detect it (for > all Synaptics touchpads, old and new). Applying this same modification > fixes these newer Synaptics touchpads and brings the driver into line > with common OS reset behaviour. > <quote end> > > > So Synaptics touchpads which are not not yet covered by their > driver need to be resetted when resuming from suspend. > > But the device we are actually talking about will be sooner or later supported > by the synaptics driver, and should all other devices who act normal be resetted > too? > > diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c > index d8c0c8d..6877371 100644 > --- a/drivers/input/mouse/psmouse-base.c > +++ b/drivers/input/mouse/psmouse-base.c > @@ -1383,6 +1383,7 @@ static int psmouse_reconnect(struct serio *serio) > struct psmouse *parent = NULL; > struct serio_driver *drv = serio->drv; > int rc = -1; > + int retries = 0; > > if (!drv || !psmouse) { > printk(KERN_DEBUG "psmouse: reconnect request, but serio is disconnected, ignoring...\n"); > @@ -1401,10 +1402,14 @@ static int psmouse_reconnect(struct serio *serio) > if (psmouse->reconnect) { > if (psmouse->reconnect(psmouse)) > goto out; > - } else if (psmouse_probe(psmouse) < 0 || > + } else { > + while ((retries++ < 3) && psmouse_reset(psmouse)) > + /* empty */; > + if (psmouse_probe(psmouse) < 0 || > psmouse->type != psmouse_extensions(psmouse, > psmouse_max_proto, false)) { > - goto out; > + goto out; > + } > } > > /* ok, the device type (and capabilities) match the old one, > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-22 21:48 ` Peter M. Petrakis @ 2010-04-22 21:55 ` Dmitry Torokhov 2010-04-23 0:47 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-22 21:55 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Christoph Fritz, linux-input, rubini On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > Hi, > > This one is a winner. with regards to your follow up. I wouldn't > want to reset something unless we have cause to. This code > seems to be doing the right thing e.g. I see "unable to query > synaptics hardware" followed by it's (re)discovery on return > from S3. > > When it's fully supported by the Synaptics driver, the initial > reconnect will succeed and we'll never get to this additional > failsafe code which is essentially a catch all for the bleeding > edge. > I am confused here... what protocol does the kernel select upon fresh boot? It is SynPS/2 or PS/2? I fit is SYnPS/2 then the touchpad is being driven by SYnaptics protocol even though we do not fully support multitouch version of SYnaptics touchpads. And i fi ti is the case then the workaround shoudl go into synaptics-sepcific reconnect function, not generic psmouse one. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-22 21:55 ` Dmitry Torokhov @ 2010-04-23 0:47 ` Christoph Fritz 2010-04-23 16:53 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-23 0:47 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Peter M. Petrakis, linux-input, rubini Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: > On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > > Hi, > > > > This one is a winner. with regards to your follow up. I wouldn't > > want to reset something unless we have cause to. This code > > seems to be doing the right thing e.g. I see "unable to query > > synaptics hardware" followed by it's (re)discovery on return > > from S3. > > > > When it's fully supported by the Synaptics driver, the initial > > reconnect will succeed and we'll never get to this additional > > failsafe code which is essentially a catch all for the bleeding > > edge. > > > > I am confused here... what protocol does the kernel select upon fresh > boot? Peter's dmesg: [ 7.428561] Unable to query Synaptics hardware. It's plain PS/2 or IMPS/2 because this bleeding edge device fails somewehre in synaptics_query_hardware(). Most likely the test on priv->identity. [ 8.239494] input: PS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input12 This is the normal KERN_INFO printk of input_register_device() which does not mean that it's using the synaptics driver. "PS/2 Synaptics TouchPad" is just the name of the device. in conclusion: If a Synaptics touchpad can't be initialized (synaptics_init) and falls back to PS/2, it doesn't get a psmouse_reset() after resuming from suspend as it would get with a synaptics driver. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-23 0:47 ` Christoph Fritz @ 2010-04-23 16:53 ` Dmitry Torokhov 2010-04-23 18:46 ` Peter M. Petrakis 2010-04-24 1:22 ` Christoph Fritz 0 siblings, 2 replies; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-23 16:53 UTC (permalink / raw) To: Christoph Fritz; +Cc: Peter M. Petrakis, linux-input, rubini On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: > > On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > > > Hi, > > > > > > This one is a winner. with regards to your follow up. I wouldn't > > > want to reset something unless we have cause to. This code > > > seems to be doing the right thing e.g. I see "unable to query > > > synaptics hardware" followed by it's (re)discovery on return > > > from S3. > > > > > > When it's fully supported by the Synaptics driver, the initial > > > reconnect will succeed and we'll never get to this additional > > > failsafe code which is essentially a catch all for the bleeding > > > edge. > > > > I am confused here... what protocol does the kernel select upon fresh > > boot? > > Peter's dmesg: > > [ 7.428561] Unable to query Synaptics hardware. > > It's plain PS/2 or IMPS/2 because this bleeding edge device fails > somewehre in synaptics_query_hardware(). Most likely the test on > priv->identity. Ah, I missed that. Peter, could you boot with i8042.debug so we could see where exactly Synaptics detection fails? > > [ 8.239494] input: PS/2 Synaptics TouchPad as > /devices/platform/i8042/serio1/input/input12 > > This is the normal KERN_INFO printk of input_register_device() which does > not mean that it's using the synaptics driver. "PS/2 Synaptics TouchPad" > is just the name of the device. > > in conclusion: > If a Synaptics touchpad can't be initialized (synaptics_init) and falls > back to PS/2, it doesn't get a psmouse_reset() after resuming from > suspend as it would get with a synaptics driver. Yes, you are right. Maybe we should just reset psmouse unconditionally in psmouse_reconnect() before actually doing any protocol reconnect/reprobe. That should help in cases when users not enable Synaptics support; also it is probably unlikely that mouse that was there gets unplugged after resume. -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-23 16:53 ` Dmitry Torokhov @ 2010-04-23 18:46 ` Peter M. Petrakis 2010-04-28 17:07 ` Dmitry Torokhov 2010-04-24 1:22 ` Christoph Fritz 1 sibling, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-23 18:46 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Christoph Fritz, linux-input, rubini [-- Attachment #1: Type: text/plain, Size: 2097 bytes --] Here are the dmesg boot logs with i8042.debug. On 04/23/2010 12:53 PM, Dmitry Torokhov wrote: > On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: >> Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: >>> On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: >>>> Hi, >>>> >>>> This one is a winner. with regards to your follow up. I wouldn't >>>> want to reset something unless we have cause to. This code >>>> seems to be doing the right thing e.g. I see "unable to query >>>> synaptics hardware" followed by it's (re)discovery on return >>>> from S3. >>>> >>>> When it's fully supported by the Synaptics driver, the initial >>>> reconnect will succeed and we'll never get to this additional >>>> failsafe code which is essentially a catch all for the bleeding >>>> edge. >>> >>> I am confused here... what protocol does the kernel select upon fresh >>> boot? >> >> Peter's dmesg: >> >> [ 7.428561] Unable to query Synaptics hardware. >> >> It's plain PS/2 or IMPS/2 because this bleeding edge device fails >> somewehre in synaptics_query_hardware(). Most likely the test on >> priv->identity. > > Ah, I missed that. Peter, could you boot with i8042.debug so we could see > where exactly Synaptics detection fails? > >> >> [ 8.239494] input: PS/2 Synaptics TouchPad as >> /devices/platform/i8042/serio1/input/input12 >> >> This is the normal KERN_INFO printk of input_register_device() which does >> not mean that it's using the synaptics driver. "PS/2 Synaptics TouchPad" >> is just the name of the device. >> >> in conclusion: >> If a Synaptics touchpad can't be initialized (synaptics_init) and falls >> back to PS/2, it doesn't get a psmouse_reset() after resuming from >> suspend as it would get with a synaptics driver. > > Yes, you are right. Maybe we should just reset psmouse unconditionally in > psmouse_reconnect() before actually doing any protocol reconnect/reprobe. That > should help in cases when users not enable Synaptics support; also it is > probably unlikely that mouse that was there gets unplugged after resume. > [-- Attachment #2: boot-i8042.debug.log.bz2 --] [-- Type: application/octet-stream, Size: 17491 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-23 18:46 ` Peter M. Petrakis @ 2010-04-28 17:07 ` Dmitry Torokhov 2010-04-28 20:17 ` Peter M. Petrakis 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-28 17:07 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Christoph Fritz, linux-input, rubini, Christopher Heiny On Fri, Apr 23, 2010 at 02:46:52PM -0400, Peter M. Petrakis wrote: > Here are the dmesg boot logs with i8042.debug. > > On 04/23/2010 12:53 PM, Dmitry Torokhov wrote: > > On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > >> Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: > >>> On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > >>>> Hi, > >>>> > >>>> This one is a winner. with regards to your follow up. I wouldn't > >>>> want to reset something unless we have cause to. This code > >>>> seems to be doing the right thing e.g. I see "unable to query > >>>> synaptics hardware" followed by it's (re)discovery on return > >>>> from S3. > >>>> > >>>> When it's fully supported by the Synaptics driver, the initial > >>>> reconnect will succeed and we'll never get to this additional > >>>> failsafe code which is essentially a catch all for the bleeding > >>>> edge. > >>> > >>> I am confused here... what protocol does the kernel select upon fresh > >>> boot? > >> > >> Peter's dmesg: > >> > >> [ 7.428561] Unable to query Synaptics hardware. > >> > >> It's plain PS/2 or IMPS/2 because this bleeding edge device fails > >> somewehre in synaptics_query_hardware(). Most likely the test on > >> priv->identity. > > > > Ah, I missed that. Peter, could you boot with i8042.debug so we could see > > where exactly Synaptics detection fails? > > Indeed, capability request returns "d0 00 73" whereas we expect 0x47 in the middle byte. Peter, please make sure that you do not have touchpad disabled in BIOS (at least other Dells that I seen had similar options). Cristofer, do you know by any chance why touchpad reporing firmware 7.5 would return such unexpected answer to 0x02 query? Thanks! -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-28 17:07 ` Dmitry Torokhov @ 2010-04-28 20:17 ` Peter M. Petrakis 2010-04-29 16:57 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-28 20:17 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Christoph Fritz, linux-input, rubini, Christopher Heiny Dmitry, This Dell in question do not have an option to disable the touchpad. The BIOS options are unremarkable. Peter On 04/28/2010 01:07 PM, Dmitry Torokhov wrote: > On Fri, Apr 23, 2010 at 02:46:52PM -0400, Peter M. Petrakis wrote: >> Here are the dmesg boot logs with i8042.debug. >> >> On 04/23/2010 12:53 PM, Dmitry Torokhov wrote: >>> On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: >>>> Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: >>>>> On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: >>>>>> Hi, >>>>>> >>>>>> This one is a winner. with regards to your follow up. I wouldn't >>>>>> want to reset something unless we have cause to. This code >>>>>> seems to be doing the right thing e.g. I see "unable to query >>>>>> synaptics hardware" followed by it's (re)discovery on return >>>>>> from S3. >>>>>> >>>>>> When it's fully supported by the Synaptics driver, the initial >>>>>> reconnect will succeed and we'll never get to this additional >>>>>> failsafe code which is essentially a catch all for the bleeding >>>>>> edge. >>>>> >>>>> I am confused here... what protocol does the kernel select upon fresh >>>>> boot? >>>> >>>> Peter's dmesg: >>>> >>>> [ 7.428561] Unable to query Synaptics hardware. >>>> >>>> It's plain PS/2 or IMPS/2 because this bleeding edge device fails >>>> somewehre in synaptics_query_hardware(). Most likely the test on >>>> priv->identity. >>> >>> Ah, I missed that. Peter, could you boot with i8042.debug so we could see >>> where exactly Synaptics detection fails? >>> > > Indeed, capability request returns "d0 00 73" whereas we expect 0x47 in > the middle byte. > > Peter, please make sure that you do not have touchpad disabled in BIOS > (at least other Dells that I seen had similar options). > > Cristofer, do you know by any chance why touchpad reporing firmware 7.5 > would return such unexpected answer to 0x02 query? > > Thanks! > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-28 20:17 ` Peter M. Petrakis @ 2010-04-29 16:57 ` Christoph Fritz 2010-04-29 17:46 ` Dmitry Torokhov 2010-04-30 22:37 ` Peter M. Petrakis 0 siblings, 2 replies; 34+ messages in thread From: Christoph Fritz @ 2010-04-29 16:57 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Dmitry Torokhov, linux-input, rubini, Christopher Heiny On Wed, 2010-04-28 at 16:17 -0400, Peter M. Petrakis wrote: > Dmitry, > > This Dell in question do not have an option to disable the > touchpad. The BIOS options are unremarkable. > > Peter > > On 04/28/2010 01:07 PM, Dmitry Torokhov wrote: > > On Fri, Apr 23, 2010 at 02:46:52PM -0400, Peter M. Petrakis wrote: > >> Here are the dmesg boot logs with i8042.debug. > >> > >> On 04/23/2010 12:53 PM, Dmitry Torokhov wrote: > >>> On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > >>>> Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: > >>>>> On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > >>>>>> Hi, > >>>>>> > >>>>>> This one is a winner. with regards to your follow up. I wouldn't > >>>>>> want to reset something unless we have cause to. This code > >>>>>> seems to be doing the right thing e.g. I see "unable to query > >>>>>> synaptics hardware" followed by it's (re)discovery on return > >>>>>> from S3. > >>>>>> > >>>>>> When it's fully supported by the Synaptics driver, the initial > >>>>>> reconnect will succeed and we'll never get to this additional > >>>>>> failsafe code which is essentially a catch all for the bleeding > >>>>>> edge. > >>>>> > >>>>> I am confused here... what protocol does the kernel select upon fresh > >>>>> boot? > >>>> > >>>> Peter's dmesg: > >>>> > >>>> [ 7.428561] Unable to query Synaptics hardware. > >>>> > >>>> It's plain PS/2 or IMPS/2 because this bleeding edge device fails > >>>> somewehre in synaptics_query_hardware(). Most likely the test on > >>>> priv->identity. > >>> > >>> Ah, I missed that. Peter, could you boot with i8042.debug so we could see > >>> where exactly Synaptics detection fails? > >>> > > > > Indeed, capability request returns "d0 00 73" whereas we expect 0x47 in > > the middle byte. The synaptics docu [1] about "information queries" is a bit imprecise in my view. It's clear to get "Identify TouchPad" with "E8 00 E8 00 E8 00 E8 00 E9". But as I understand it, to get "Read Capabilities" we should do "E8 02 E8 02 E8 02 E8 02 E9" instead of "E8 00 E8 00 E8 00 E8 02 E9". Peter, does the touchpad works with synaptics driver when you apply this patch below? diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index 026df60..aa25fbd 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -103,8 +103,12 @@ void synaptics_reset(struct psmouse *psmouse) */ static int synaptics_send_cmd(struct psmouse *psmouse, unsigned char c, unsigned char *param) { - if (psmouse_sliced_command(psmouse, c)) - return -1; + int i; + + for (i = 0; i < 4; i++) { + if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_SETRES)) + return -1; + } if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETINFO)) return -1; return 0; --- Thanks, chf [1]: http://www.synaptics.com/sites/default/files/511-000275-01rA.pdf ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-29 16:57 ` Christoph Fritz @ 2010-04-29 17:46 ` Dmitry Torokhov 2010-04-30 22:37 ` Peter M. Petrakis 1 sibling, 0 replies; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-29 17:46 UTC (permalink / raw) To: Christoph Fritz; +Cc: Peter M. Petrakis, linux-input, rubini, Christopher Heiny On Thursday 29 April 2010 09:57:48 am Christoph Fritz wrote: > On Wed, 2010-04-28 at 16:17 -0400, Peter M. Petrakis wrote: > > Dmitry, > > > > This Dell in question do not have an option to disable the > > touchpad. The BIOS options are unremarkable. > > > > Peter > > > > On 04/28/2010 01:07 PM, Dmitry Torokhov wrote: > > > On Fri, Apr 23, 2010 at 02:46:52PM -0400, Peter M. Petrakis wrote: > > >> Here are the dmesg boot logs with i8042.debug. > > >> > > >> On 04/23/2010 12:53 PM, Dmitry Torokhov wrote: > > >>> On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > > >>>> Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: > > >>>>> On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> This one is a winner. with regards to your follow up. I wouldn't > > >>>>>> want to reset something unless we have cause to. This code > > >>>>>> seems to be doing the right thing e.g. I see "unable to query > > >>>>>> synaptics hardware" followed by it's (re)discovery on return > > >>>>>> from S3. > > >>>>>> > > >>>>>> When it's fully supported by the Synaptics driver, the initial > > >>>>>> reconnect will succeed and we'll never get to this additional > > >>>>>> failsafe code which is essentially a catch all for the bleeding > > >>>>>> edge. > > >>>>> > > >>>>> I am confused here... what protocol does the kernel select upon > > >>>>> fresh boot? > > >>>> > > >>>> Peter's dmesg: > > >>>> > > >>>> [ 7.428561] Unable to query Synaptics hardware. > > >>>> > > >>>> It's plain PS/2 or IMPS/2 because this bleeding edge device fails > > >>>> > > >>>> somewehre in synaptics_query_hardware(). Most likely the test on > > >>>> priv->identity. > > >>> > > >>> Ah, I missed that. Peter, could you boot with i8042.debug so we could > > >>> see where exactly Synaptics detection fails? > > > > > > Indeed, capability request returns "d0 00 73" whereas we expect 0x47 in > > > the middle byte. > > The synaptics docu [1] about "information queries" is a bit imprecise in > my view. It's clear to get "Identify TouchPad" with "E8 00 E8 00 E8 00 > E8 00 E9". But as I understand it, to get "Read Capabilities" we should > do "E8 02 E8 02 E8 02 E8 02 E9" instead of "E8 00 E8 00 E8 00 E8 02 E9". No, E8 sequence is described very clearly in p 4.2 of the interfacing guide. 02 02 02 02 would correspond to 0xaa I believe. -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-29 16:57 ` Christoph Fritz 2010-04-29 17:46 ` Dmitry Torokhov @ 2010-04-30 22:37 ` Peter M. Petrakis 2010-05-02 3:07 ` Christoph Fritz 1 sibling, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-04-30 22:37 UTC (permalink / raw) To: Christoph Fritz; +Cc: Dmitry Torokhov, linux-input, rubini, Christopher Heiny [-- Attachment #1: Type: text/plain, Size: 3244 bytes --] Christoph, The setres cmds don't seem to be working. We end up falling back to the generic driver again and failing in psmouse_probe. Logs attached with some instrumentation and i8042.debug enabled. Peter On 04/29/2010 12:57 PM, Christoph Fritz wrote: > On Wed, 2010-04-28 at 16:17 -0400, Peter M. Petrakis wrote: >> Dmitry, >> >> This Dell in question do not have an option to disable the >> touchpad. The BIOS options are unremarkable. >> >> Peter >> >> On 04/28/2010 01:07 PM, Dmitry Torokhov wrote: >>> On Fri, Apr 23, 2010 at 02:46:52PM -0400, Peter M. Petrakis wrote: >>>> Here are the dmesg boot logs with i8042.debug. >>>> >>>> On 04/23/2010 12:53 PM, Dmitry Torokhov wrote: >>>>> On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: >>>>>> Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov: >>>>>>> On Thu, Apr 22, 2010 at 05:48:21PM -0400, Peter M. Petrakis wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This one is a winner. with regards to your follow up. I wouldn't >>>>>>>> want to reset something unless we have cause to. This code >>>>>>>> seems to be doing the right thing e.g. I see "unable to query >>>>>>>> synaptics hardware" followed by it's (re)discovery on return >>>>>>>> from S3. >>>>>>>> >>>>>>>> When it's fully supported by the Synaptics driver, the initial >>>>>>>> reconnect will succeed and we'll never get to this additional >>>>>>>> failsafe code which is essentially a catch all for the bleeding >>>>>>>> edge. >>>>>>> >>>>>>> I am confused here... what protocol does the kernel select upon fresh >>>>>>> boot? >>>>>> >>>>>> Peter's dmesg: >>>>>> >>>>>> [ 7.428561] Unable to query Synaptics hardware. >>>>>> >>>>>> It's plain PS/2 or IMPS/2 because this bleeding edge device fails >>>>>> somewehre in synaptics_query_hardware(). Most likely the test on >>>>>> priv->identity. >>>>> >>>>> Ah, I missed that. Peter, could you boot with i8042.debug so we could see >>>>> where exactly Synaptics detection fails? >>>>> >>> >>> Indeed, capability request returns "d0 00 73" whereas we expect 0x47 in >>> the middle byte. > > The synaptics docu [1] about "information queries" is a bit imprecise in > my view. It's clear to get "Identify TouchPad" with "E8 00 E8 00 E8 00 > E8 00 E9". But as I understand it, to get "Read Capabilities" we should > do "E8 02 E8 02 E8 02 E8 02 E9" instead of "E8 00 E8 00 E8 00 E8 02 E9". > > Peter, does the touchpad works with synaptics driver when you apply this > patch below? > > diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c > index 026df60..aa25fbd 100644 > --- a/drivers/input/mouse/synaptics.c > +++ b/drivers/input/mouse/synaptics.c > @@ -103,8 +103,12 @@ void synaptics_reset(struct psmouse *psmouse) > */ > static int synaptics_send_cmd(struct psmouse *psmouse, unsigned char c, unsigned char *param) > { > - if (psmouse_sliced_command(psmouse, c)) > - return -1; > + int i; > + > + for (i = 0; i < 4; i++) { > + if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_SETRES)) > + return -1; > + } > if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_GETINFO)) > return -1; > return 0; > --- > > Thanks, > chf > > [1]: http://www.synaptics.com/sites/default/files/511-000275-01rA.pdf > > [-- Attachment #2: resume_i8042.debug_setres.log.bz2 --] [-- Type: application/x-bzip, Size: 15593 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-30 22:37 ` Peter M. Petrakis @ 2010-05-02 3:07 ` Christoph Fritz 2010-05-02 7:41 ` Christoph Fritz 2010-05-07 17:57 ` Peter M. Petrakis 0 siblings, 2 replies; 34+ messages in thread From: Christoph Fritz @ 2010-05-02 3:07 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Dmitry Torokhov, linux-input, rubini, Christopher Heiny Am Freitag, den 30.04.2010, 18:37 -0400 schrieb Peter M. Petrakis: > Christoph, > > The setres cmds don't seem to be working. We end up falling > back to the generic driver again and failing in psmouse_probe. > Logs attached with some instrumentation and i8042.debug enabled. As Dmitry already told, this "E8 02 E8 02 E8 02 E8 02 E9" is nonsene. I missed part 4.4 in the docu. There was no need to test, sorry to not making this more clear. At the moment there are two open questions: 1. Why does the device report itself as 0x73 when we expect 0x47 to special query 0x02? Christopher from Synaptics has been already asked. By the way, this 0x73 is the cause why your device falls back to ps2 driver. It's the root of your suspend problem: synaptics driver does, psmouse-base does no reset in reconnect(). 2. Should we do a reset in psmouse-base too? If yes, only for these "fall-back-synaptic-touchpads" or should all generic ps2 devices get a reset? Here I missused the model entry, but it's not that fine: diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index d8c0c8d..5e726df 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -597,7 +597,6 @@ static int cortron_detect(struct psmouse *psmouse, bool set_properties) static int psmouse_extensions(struct psmouse *psmouse, unsigned int max_proto, bool set_properties) { - bool synaptics_hardware = false; /* * We always check for lifebook because it does not disturb mouse @@ -621,10 +620,10 @@ static int psmouse_extensions(struct psmouse *psmouse, /* * Try Synaptics TouchPad. Note that probing is done even if Synaptics protocol * support is disabled in config - we need to know if it is synaptics so we - * can reset it properly after probing for intellimouse. + * can reset it properly at reconnect and after probing for intellimouse. */ if (max_proto > PSMOUSE_PS2 && synaptics_detect(psmouse, set_properties) == 0) { - synaptics_hardware = true; + psmouse->model = PSMOUSE_MODEL_NEEDRESET; if (max_proto > PSMOUSE_IMEX) { /* @@ -740,7 +739,7 @@ static int psmouse_extensions(struct psmouse *psmouse, */ ps2bare_detect(psmouse, set_properties); - if (synaptics_hardware) { + if (psmouse->model == PSMOUSE_MODEL_NEEDRESET) { /* * We detected Synaptics hardware but it did not respond to IMPS/2 probes. * We need to reset the touchpad because if there is a track point on the @@ -1401,10 +1400,14 @@ static int psmouse_reconnect(struct serio *serio) if (psmouse->reconnect) { if (psmouse->reconnect(psmouse)) goto out; - } else if (psmouse_probe(psmouse) < 0 || + } else { + if (psmouse->model == PSMOUSE_MODEL_NEEDRESET) + psmouse_reset(psmouse); + if (psmouse_probe(psmouse) < 0 || psmouse->type != psmouse_extensions(psmouse, psmouse_max_proto, false)) { - goto out; + goto out; + } } /* ok, the device type (and capabilities) match the old one, diff --git a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h index e053bdd..c45b5ef 100644 --- a/drivers/input/mouse/psmouse.h +++ b/drivers/input/mouse/psmouse.h @@ -20,6 +20,9 @@ #define PSMOUSE_RET_ACK 0xfa #define PSMOUSE_RET_NAK 0xfe +#define PSMOUSE_MODEL_UNKNOWN 0x00 +#define PSMOUSE_MODEL_NEEDRESET 0x01 + enum psmouse_state { PSMOUSE_IGNORE, PSMOUSE_INITIALIZING, ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-05-02 3:07 ` Christoph Fritz @ 2010-05-02 7:41 ` Christoph Fritz 2010-05-07 17:57 ` Peter M. Petrakis 1 sibling, 0 replies; 34+ messages in thread From: Christoph Fritz @ 2010-05-02 7:41 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Dmitry Torokhov, linux-input, rubini, Christopher Heiny On Sun, 2010-05-02 at 05:07 +0200, Christoph Fritz wrote: > Am Freitag, den 30.04.2010, 18:37 -0400 schrieb Peter M. Petrakis: > > Christoph, > > > > The setres cmds don't seem to be working. We end up falling > > back to the generic driver again and failing in psmouse_probe. > > Logs attached with some instrumentation and i8042.debug enabled. > > As Dmitry already told, this "E8 02 E8 02 E8 02 E8 02 E9" is nonsene. I > missed part 4.4 in the docu. There was no need to test, sorry to not > making this more clear. > > At the moment there are two open questions: > > 1. Why does the device report itself as 0x73 0x00, shouldn't write emails that late... > when we expect 0x47 to > special query 0x02? Christopher from Synaptics has been already asked. > By the way, this 0x73 0x00 > is the cause why your device falls back to ps2 > driver. It's the root of your suspend problem: synaptics driver does, > psmouse-base does no reset in reconnect(). > > 2. Should we do a reset in psmouse-base too? If yes, only for these > "fall-back-synaptic-touchpads" or should all generic ps2 devices get a > reset? > > Here I missused the model entry, but it's not that fine: > > diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c > index d8c0c8d..5e726df 100644 > --- a/drivers/input/mouse/psmouse-base.c > +++ b/drivers/input/mouse/psmouse-base.c > @@ -597,7 +597,6 @@ static int cortron_detect(struct psmouse *psmouse, bool set_properties) > static int psmouse_extensions(struct psmouse *psmouse, > unsigned int max_proto, bool set_properties) > { > - bool synaptics_hardware = false; > > /* > * We always check for lifebook because it does not disturb mouse > @@ -621,10 +620,10 @@ static int psmouse_extensions(struct psmouse *psmouse, > /* > * Try Synaptics TouchPad. Note that probing is done even if Synaptics protocol > * support is disabled in config - we need to know if it is synaptics so we > - * can reset it properly after probing for intellimouse. > + * can reset it properly at reconnect and after probing for intellimouse. > */ > if (max_proto > PSMOUSE_PS2 && synaptics_detect(psmouse, set_properties) == 0) { > - synaptics_hardware = true; > + psmouse->model = PSMOUSE_MODEL_NEEDRESET; > > if (max_proto > PSMOUSE_IMEX) { > /* > @@ -740,7 +739,7 @@ static int psmouse_extensions(struct psmouse *psmouse, > */ > ps2bare_detect(psmouse, set_properties); > > - if (synaptics_hardware) { > + if (psmouse->model == PSMOUSE_MODEL_NEEDRESET) { > /* > * We detected Synaptics hardware but it did not respond to IMPS/2 probes. > * We need to reset the touchpad because if there is a track point on the > @@ -1401,10 +1400,14 @@ static int psmouse_reconnect(struct serio *serio) > if (psmouse->reconnect) { > if (psmouse->reconnect(psmouse)) > goto out; > - } else if (psmouse_probe(psmouse) < 0 || > + } else { > + if (psmouse->model == PSMOUSE_MODEL_NEEDRESET) > + psmouse_reset(psmouse); > + if (psmouse_probe(psmouse) < 0 || > psmouse->type != psmouse_extensions(psmouse, > psmouse_max_proto, false)) { > - goto out; > + goto out; > + } > } > > /* ok, the device type (and capabilities) match the old one, > diff --git a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h > index e053bdd..c45b5ef 100644 > --- a/drivers/input/mouse/psmouse.h > +++ b/drivers/input/mouse/psmouse.h > @@ -20,6 +20,9 @@ > #define PSMOUSE_RET_ACK 0xfa > #define PSMOUSE_RET_NAK 0xfe > > +#define PSMOUSE_MODEL_UNKNOWN 0x00 > +#define PSMOUSE_MODEL_NEEDRESET 0x01 > + > enum psmouse_state { > PSMOUSE_IGNORE, > PSMOUSE_INITIALIZING, > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-05-02 3:07 ` Christoph Fritz 2010-05-02 7:41 ` Christoph Fritz @ 2010-05-07 17:57 ` Peter M. Petrakis 2010-05-08 16:01 ` Christoph Fritz 1 sibling, 1 reply; 34+ messages in thread From: Peter M. Petrakis @ 2010-05-07 17:57 UTC (permalink / raw) To: Christoph Fritz; +Cc: Dmitry Torokhov, linux-input, rubini, Christopher Heiny So where do we stand on this? Option #2 sounds like a good thing to implement regardless of whether synaptics is the victim device or not. Devices supported by the fall back driver will eventually get our attention again when users wish to use the extended features of the device. In the meanwhile, at least they'll have a reliable, minimum set of features. I'm happy to continue instrumenting this mysterious synaptics device. Just keep the patches coming. Thanks. Peter On 05/01/2010 11:07 PM, Christoph Fritz wrote: > Am Freitag, den 30.04.2010, 18:37 -0400 schrieb Peter M. Petrakis: >> Christoph, >> >> The setres cmds don't seem to be working. We end up falling >> back to the generic driver again and failing in psmouse_probe. >> Logs attached with some instrumentation and i8042.debug enabled. > > As Dmitry already told, this "E8 02 E8 02 E8 02 E8 02 E9" is nonsene. I > missed part 4.4 in the docu. There was no need to test, sorry to not > making this more clear. > > At the moment there are two open questions: > > 1. Why does the device report itself as 0x73 when we expect 0x47 to > special query 0x02? Christopher from Synaptics has been already asked. > By the way, this 0x73 is the cause why your device falls back to ps2 > driver. It's the root of your suspend problem: synaptics driver does, > psmouse-base does no reset in reconnect(). > > 2. Should we do a reset in psmouse-base too? If yes, only for these > "fall-back-synaptic-touchpads" or should all generic ps2 devices get a > reset? > > Here I missused the model entry, but it's not that fine: > > diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c > index d8c0c8d..5e726df 100644 > --- a/drivers/input/mouse/psmouse-base.c > +++ b/drivers/input/mouse/psmouse-base.c > @@ -597,7 +597,6 @@ static int cortron_detect(struct psmouse *psmouse, bool set_properties) > static int psmouse_extensions(struct psmouse *psmouse, > unsigned int max_proto, bool set_properties) > { > - bool synaptics_hardware = false; > > /* > * We always check for lifebook because it does not disturb mouse > @@ -621,10 +620,10 @@ static int psmouse_extensions(struct psmouse *psmouse, > /* > * Try Synaptics TouchPad. Note that probing is done even if Synaptics protocol > * support is disabled in config - we need to know if it is synaptics so we > - * can reset it properly after probing for intellimouse. > + * can reset it properly at reconnect and after probing for intellimouse. > */ > if (max_proto> PSMOUSE_PS2&& synaptics_detect(psmouse, set_properties) == 0) { > - synaptics_hardware = true; > + psmouse->model = PSMOUSE_MODEL_NEEDRESET; > > if (max_proto> PSMOUSE_IMEX) { > /* > @@ -740,7 +739,7 @@ static int psmouse_extensions(struct psmouse *psmouse, > */ > ps2bare_detect(psmouse, set_properties); > > - if (synaptics_hardware) { > + if (psmouse->model == PSMOUSE_MODEL_NEEDRESET) { > /* > * We detected Synaptics hardware but it did not respond to IMPS/2 probes. > * We need to reset the touchpad because if there is a track point on the > @@ -1401,10 +1400,14 @@ static int psmouse_reconnect(struct serio *serio) > if (psmouse->reconnect) { > if (psmouse->reconnect(psmouse)) > goto out; > - } else if (psmouse_probe(psmouse)< 0 || > + } else { > + if (psmouse->model == PSMOUSE_MODEL_NEEDRESET) > + psmouse_reset(psmouse); > + if (psmouse_probe(psmouse)< 0 || > psmouse->type != psmouse_extensions(psmouse, > psmouse_max_proto, false)) { > - goto out; > + goto out; > + } > } > > /* ok, the device type (and capabilities) match the old one, > diff --git a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h > index e053bdd..c45b5ef 100644 > --- a/drivers/input/mouse/psmouse.h > +++ b/drivers/input/mouse/psmouse.h > @@ -20,6 +20,9 @@ > #define PSMOUSE_RET_ACK 0xfa > #define PSMOUSE_RET_NAK 0xfe > > +#define PSMOUSE_MODEL_UNKNOWN 0x00 > +#define PSMOUSE_MODEL_NEEDRESET 0x01 > + > enum psmouse_state { > PSMOUSE_IGNORE, > PSMOUSE_INITIALIZING, > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-05-07 17:57 ` Peter M. Petrakis @ 2010-05-08 16:01 ` Christoph Fritz 0 siblings, 0 replies; 34+ messages in thread From: Christoph Fritz @ 2010-05-08 16:01 UTC (permalink / raw) To: Peter M. Petrakis; +Cc: Dmitry Torokhov, linux-input, rubini, Christopher Heiny On Fri, 2010-05-07 at 13:57 -0400, Peter M. Petrakis wrote: > So where do we stand on this? Option #2 sounds like a good > thing to implement regardless of whether synaptics is the > victim device or not. Devices supported by the fall back driver > will eventually get our attention again when users wish to use > the extended features of the device. In the meanwhile, at least > they'll have a reliable, minimum set of features. > > I'm happy to continue instrumenting this mysterious synaptics > device. Just keep the patches coming. Thanks. You can wipe out this (maybe for firmware >7.5 obsolete) 0x47 check in synaptics_capability() and see if it works with synaptics driver. diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c index 026df60..6750dbb 100644 --- a/drivers/input/mouse/synaptics.c +++ b/drivers/input/mouse/synaptics.c @@ -138,7 +138,9 @@ static int synaptics_capability(struct psmouse *psmouse) return -1; priv->capabilities = (cap[0] << 16) | (cap[1] << 8) | cap[2]; priv->ext_cap = 0; - if (!SYN_CAP_VALID(priv->capabilities)) + if (!SYN_CAP_VALID(priv->capabilities) && + SYN_ID_MAJOR(priv->identity) < 7 && + SYN_ID_MINOR(priv->identity) < 5) return -1; /* ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-23 16:53 ` Dmitry Torokhov 2010-04-23 18:46 ` Peter M. Petrakis @ 2010-04-24 1:22 ` Christoph Fritz 2010-04-24 10:00 ` Christoph Fritz 1 sibling, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-24 1:22 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Peter M. Petrakis, linux-input, rubini On Fri, 2010-04-23 at 09:53 -0700, Dmitry Torokhov wrote: > On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > > in conclusion: > > If a Synaptics touchpad can't be initialized (synaptics_init) and falls > > back to PS/2, it doesn't get a psmouse_reset() after resuming from > > suspend as it would get with a synaptics driver. > > Yes, you are right. Maybe we should just reset psmouse unconditionally in > psmouse_reconnect() before actually doing any protocol reconnect/reprobe. That > should help in cases when users not enable Synaptics support; also it is > probably unlikely that mouse that was there gets unplugged after resume. Yes, this would solve that case too. Maybe if we take that "unconditionally-reset-step", what about taking the full step and getting rid of the whole i8042_dmi_reset_table quirk stuff and doing unconditionally resets there too? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-24 1:22 ` Christoph Fritz @ 2010-04-24 10:00 ` Christoph Fritz 2010-04-28 7:26 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-04-24 10:00 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Peter M. Petrakis, linux-input, rubini On Sat, 2010-04-24 at 03:22 +0200, Christoph Fritz wrote: > On Fri, 2010-04-23 at 09:53 -0700, Dmitry Torokhov wrote: > > On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > > > > in conclusion: > > > If a Synaptics touchpad can't be initialized (synaptics_init) and falls > > > back to PS/2, it doesn't get a psmouse_reset() after resuming from > > > suspend as it would get with a synaptics driver. > > > > Yes, you are right. Maybe we should just reset psmouse unconditionally in > > psmouse_reconnect() before actually doing any protocol reconnect/reprobe. That > > should help in cases when users not enable Synaptics support; also it is > > probably unlikely that mouse that was there gets unplugged after resume. > > Yes, this would solve that case too. I have to correct myself. The case is already achieved with the patch I sent: synaptics_detect() detects presence of synaptics_hardware even if the user does not enable CONFIG_MOUSE_PS2_SYNAPTICS. Just for a better overview in this thread, here it is: --- If a Synaptics touchpad can't be initialized (synaptics_init) and falls back to PS/2, it doesn't get a psmouse_reset() after resuming from suspend as it would get with a synaptics driver. So check state of synaptics_hardware and reset this beast. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> --- drivers/input/mouse/psmouse-base.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index d8c0c8d..66ce0ac 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -116,6 +116,9 @@ struct psmouse_protocol { int (*init)(struct psmouse *); }; +/* to handle some reset quirks */ +static bool synaptics_hardware = false; + /* * psmouse_process_byte() analyzes the PS/2 data stream and reports * relevant events to the input module once full packet has arrived. @@ -597,7 +600,6 @@ static int cortron_detect(struct psmouse *psmouse, bool set_properties) static int psmouse_extensions(struct psmouse *psmouse, unsigned int max_proto, bool set_properties) { - bool synaptics_hardware = false; /* * We always check for lifebook because it does not disturb mouse @@ -1401,10 +1403,14 @@ static int psmouse_reconnect(struct serio *serio) if (psmouse->reconnect) { if (psmouse->reconnect(psmouse)) goto out; - } else if (psmouse_probe(psmouse) < 0 || + } else { + if (synaptics_hardware) /* is using plain PS/2 */ + psmouse_reset(psmouse); + if (psmouse_probe(psmouse) < 0 || psmouse->type != psmouse_extensions(psmouse, psmouse_max_proto, false)) { - goto out; + goto out; + } } /* ok, the device type (and capabilities) match the old one, -- 1.5.6.5 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-24 10:00 ` Christoph Fritz @ 2010-04-28 7:26 ` Dmitry Torokhov 2010-05-08 16:22 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-04-28 7:26 UTC (permalink / raw) To: Christoph Fritz; +Cc: Peter M. Petrakis, linux-input, rubini On Sat, Apr 24, 2010 at 12:00:33PM +0200, Christoph Fritz wrote: > On Sat, 2010-04-24 at 03:22 +0200, Christoph Fritz wrote: > > On Fri, 2010-04-23 at 09:53 -0700, Dmitry Torokhov wrote: > > > On Thursday 22 April 2010 05:47:48 pm Christoph Fritz wrote: > > > > > > in conclusion: > > > > If a Synaptics touchpad can't be initialized (synaptics_init) and falls > > > > back to PS/2, it doesn't get a psmouse_reset() after resuming from > > > > suspend as it would get with a synaptics driver. > > > > > > Yes, you are right. Maybe we should just reset psmouse unconditionally in > > > psmouse_reconnect() before actually doing any protocol reconnect/reprobe. That > > > should help in cases when users not enable Synaptics support; also it is > > > probably unlikely that mouse that was there gets unplugged after resume. > > > > Yes, this would solve that case too. > > I have to correct myself. > The case is already achieved with the patch I sent: > synaptics_detect() detects presence of synaptics_hardware even if the user > does not enable CONFIG_MOUSE_PS2_SYNAPTICS. > > Just for a better overview in this thread, here it is: > > > --- > If a Synaptics touchpad can't be initialized (synaptics_init) and falls > back to PS/2, it doesn't get a psmouse_reset() after resuming from > suspend as it would get with a synaptics driver. > So check state of synaptics_hardware and reset this beast. > > Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> > --- > drivers/input/mouse/psmouse-base.c | 12 +++++++++--- > 1 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c > index d8c0c8d..66ce0ac 100644 > --- a/drivers/input/mouse/psmouse-base.c > +++ b/drivers/input/mouse/psmouse-base.c > @@ -116,6 +116,9 @@ struct psmouse_protocol { > int (*init)(struct psmouse *); > }; > > +/* to handle some reset quirks */ > +static bool synaptics_hardware = false; This is not entirely correct as there could be more than one PS/2 device attached to a box (i.e. a touchpad and an external mouse). What about simply resetting the mouse before actually trying to reconnect? BTW, no need to initialize static variables to 0/false. > + > /* > * psmouse_process_byte() analyzes the PS/2 data stream and reports > * relevant events to the input module once full packet has arrived. > @@ -597,7 +600,6 @@ static int cortron_detect(struct psmouse *psmouse, bool set_properties) > static int psmouse_extensions(struct psmouse *psmouse, > unsigned int max_proto, bool set_properties) > { > - bool synaptics_hardware = false; > > /* > * We always check for lifebook because it does not disturb mouse > @@ -1401,10 +1403,14 @@ static int psmouse_reconnect(struct serio *serio) > if (psmouse->reconnect) { > if (psmouse->reconnect(psmouse)) > goto out; > - } else if (psmouse_probe(psmouse) < 0 || > + } else { > + if (synaptics_hardware) /* is using plain PS/2 */ > + psmouse_reset(psmouse); > + if (psmouse_probe(psmouse) < 0 || > psmouse->type != psmouse_extensions(psmouse, > psmouse_max_proto, false)) { > - goto out; > + goto out; > + } > } > > /* ok, the device type (and capabilities) match the old one, Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-04-28 7:26 ` Dmitry Torokhov @ 2010-05-08 16:22 ` Christoph Fritz 2010-05-11 8:22 ` Dmitry Torokhov 0 siblings, 1 reply; 34+ messages in thread From: Christoph Fritz @ 2010-05-08 16:22 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Peter M. Petrakis, linux-input, rubini On Wed, 2010-04-28 at 00:26 -0700, Dmitry Torokhov wrote: > What about simply resetting the mouse before actually trying to > reconnect? Isn't psmouse_reconnect() the first in psmouse-base.c that gets called after waking up from hibernation/suspend? And should all ps2 devices get a reset or only the one which needs it (synaptic touchpads not handled by synaptics driver)? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-05-08 16:22 ` Christoph Fritz @ 2010-05-11 8:22 ` Dmitry Torokhov 2010-05-11 22:24 ` Christoph Fritz 0 siblings, 1 reply; 34+ messages in thread From: Dmitry Torokhov @ 2010-05-11 8:22 UTC (permalink / raw) To: Christoph Fritz; +Cc: Peter M. Petrakis, linux-input, rubini On Sat, May 08, 2010 at 06:22:09PM +0200, Christoph Fritz wrote: > On Wed, 2010-04-28 at 00:26 -0700, Dmitry Torokhov wrote: > > > What about simply resetting the mouse before actually trying to > > reconnect? > > Isn't psmouse_reconnect() the first in psmouse-base.c that gets called > after waking up from hibernation/suspend? > And should all ps2 devices get a reset or only the one which needs it > (synaptic touchpads not handled by synaptics driver)? > I think we should reset all devcices that do not provide reconnect method (this includes Synaptics hardware in bare PS/2 mode). Something like below. -- Dmitry Input: psmouse - reset all types of mice before reconnecting From: Dmitry Torokhov <dmitry.torokhov@gmail.com> Synaptics hardware requires resetting device after suspend to ram in order for the device to be operational. The reset lives in synaptics-specific reconnect handler, but it is not being invoked if synaptics support is disabled and the device is handled as a standard PS/2 device (bare or IntelliMouse protocol). Let's add reset into generic reconnect handler as well. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> --- drivers/input/mouse/psmouse-base.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index cbc8072..a3c9731 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -1394,6 +1394,7 @@ static int psmouse_reconnect(struct serio *serio) struct psmouse *psmouse = serio_get_drvdata(serio); struct psmouse *parent = NULL; struct serio_driver *drv = serio->drv; + unsigned char type; int rc = -1; if (!drv || !psmouse) { @@ -1413,10 +1414,15 @@ static int psmouse_reconnect(struct serio *serio) if (psmouse->reconnect) { if (psmouse->reconnect(psmouse)) goto out; - } else if (psmouse_probe(psmouse) < 0 || - psmouse->type != psmouse_extensions(psmouse, - psmouse_max_proto, false)) { - goto out; + } else { + psmouse_reset(psmouse); + + if (psmouse_probe(psmouse) < 0) + goto out; + + type = psmouse_extensions(psmouse, psmouse_max_proto, false); + if (psmouse->type != type) + goto out; } /* ok, the device type (and capabilities) match the old one, ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying 2010-05-11 8:22 ` Dmitry Torokhov @ 2010-05-11 22:24 ` Christoph Fritz 0 siblings, 0 replies; 34+ messages in thread From: Christoph Fritz @ 2010-05-11 22:24 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Peter M. Petrakis, linux-input, rubini On Tue, 2010-05-11 at 01:22 -0700, Dmitry Torokhov wrote: > On Sat, May 08, 2010 at 06:22:09PM +0200, Christoph Fritz wrote: > > On Wed, 2010-04-28 at 00:26 -0700, Dmitry Torokhov wrote: > > > > > What about simply resetting the mouse before actually trying to > > > reconnect? > > > > Isn't psmouse_reconnect() the first in psmouse-base.c that gets > called > > after waking up from hibernation/suspend? > > And should all ps2 devices get a reset or only the one which needs > it > > (synaptic touchpads not handled by synaptics driver)? > > > > I think we should reset all devcices that do not provide reconnect > method (this includes Synaptics hardware in bare PS/2 mode). Something > like below. > > -- > Dmitry > > Input: psmouse - reset all types of mice before reconnecting > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > Synaptics hardware requires resetting device after suspend to ram > in order for the device to be operational. The reset lives in > synaptics-specific reconnect handler, but it is not being invoked > if synaptics support is disabled and the device is handled as a > standard PS/2 device (bare or IntelliMouse protocol). > > Let's add reset into generic reconnect handler as well. > > Signed-off-by: Dmitry Torokhov <dtor@mail.ru> > --- > > drivers/input/mouse/psmouse-base.c | 14 ++++++++++---- > 1 files changed, 10 insertions(+), 4 deletions(-) > > > diff --git a/drivers/input/mouse/psmouse-base.c > b/drivers/input/mouse/psmouse-base.c > index cbc8072..a3c9731 100644 > --- a/drivers/input/mouse/psmouse-base.c > +++ b/drivers/input/mouse/psmouse-base.c > @@ -1394,6 +1394,7 @@ static int psmouse_reconnect(struct serio > *serio) > struct psmouse *psmouse = serio_get_drvdata(serio); > struct psmouse *parent = NULL; > struct serio_driver *drv = serio->drv; > + unsigned char type; > int rc = -1; > > if (!drv || !psmouse) { > @@ -1413,10 +1414,15 @@ static int psmouse_reconnect(struct serio > *serio) > if (psmouse->reconnect) { > if (psmouse->reconnect(psmouse)) > goto out; > - } else if (psmouse_probe(psmouse) < 0 || > - psmouse->type != psmouse_extensions(psmouse, > - psmouse_max_proto, > false)) { > - goto out; > + } else { > + psmouse_reset(psmouse); > + > + if (psmouse_probe(psmouse) < 0) > + goto out; > + > + type = psmouse_extensions(psmouse, psmouse_max_proto, > false); > + if (psmouse->type != type) > + goto out; > } > > /* ok, the device type (and capabilities) match the old one, > > This looks good and I can understand making this generic because it doesn't hurt. Thanks, Christoph ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2010-05-11 22:18 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-16 22:52 [PATCH] Reset ps/2 port should psmouse_probe fail before retrying Peter M. Petrakis 2010-04-17 11:01 ` Christoph Fritz 2010-04-17 15:31 ` Peter M. Petrakis 2010-04-17 16:53 ` Christoph Fritz 2010-04-19 15:33 ` Peter M. Petrakis 2010-04-20 0:37 ` Christoph Fritz 2010-04-20 21:08 ` Peter M. Petrakis 2010-04-21 6:33 ` Dmitry Torokhov 2010-04-21 16:05 ` Peter M. Petrakis 2010-04-21 17:10 ` Dmitry Torokhov 2010-04-21 19:38 ` Peter M. Petrakis 2010-04-21 19:52 ` Dmitry Torokhov 2010-04-21 21:10 ` Peter M. Petrakis 2010-04-22 16:28 ` Christoph Fritz 2010-04-22 21:48 ` Peter M. Petrakis 2010-04-22 21:55 ` Dmitry Torokhov 2010-04-23 0:47 ` Christoph Fritz 2010-04-23 16:53 ` Dmitry Torokhov 2010-04-23 18:46 ` Peter M. Petrakis 2010-04-28 17:07 ` Dmitry Torokhov 2010-04-28 20:17 ` Peter M. Petrakis 2010-04-29 16:57 ` Christoph Fritz 2010-04-29 17:46 ` Dmitry Torokhov 2010-04-30 22:37 ` Peter M. Petrakis 2010-05-02 3:07 ` Christoph Fritz 2010-05-02 7:41 ` Christoph Fritz 2010-05-07 17:57 ` Peter M. Petrakis 2010-05-08 16:01 ` Christoph Fritz 2010-04-24 1:22 ` Christoph Fritz 2010-04-24 10:00 ` Christoph Fritz 2010-04-28 7:26 ` Dmitry Torokhov 2010-05-08 16:22 ` Christoph Fritz 2010-05-11 8:22 ` Dmitry Torokhov 2010-05-11 22:24 ` Christoph Fritz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).