[PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[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. 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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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();

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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?
> 

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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().
> 

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

[-- 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 --]

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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,

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[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? 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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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.

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

[-- 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 --]

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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?

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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!
> 

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

[-- 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 --]

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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,

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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,
> 
> 

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

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,
>
>

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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;
 
 	/*

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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)?

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Dmitry Torokhov]

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,

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Christoph Fritz]

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

Re: [PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Randy Dunlap]

On Wed, 14 Apr 2010 16:46:29 -0400 Peter M. Petrakis wrote:

> 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.

Hi,

Please send patches inline, not as attachments.
Use the full source file path in the patch.
Send the patch to linux-input@vger.kernel.org and cc: the Input
subsystem maintainer.

typo:  s/reseting/resetting/


Other than those 4 things, the patch looks OK to me.
Well, we would prefer not to have the
	((ret = __psmouse_probe(psmouse)) != 0)
inside the for expression if possible.  I.e., make the for(...) simpler.


Please read/review Documentation/SubmittingPatches.  Thanks.

---
~Randy

[PATCH] Reset ps/2 port should psmouse_probe fail before retrying

[Peter M. Petrakis]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

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



[-- Attachment #2: psmouse_reset.patch --]
[-- Type: text/x-diff, Size: 1181 bytes --]

diff --git a/psmouse-base.c b/psmouse-base.c
index b407b35..d79eafc 100644
--- a/psmouse-base.c
+++ b/psmouse-base.c
@@ -856,12 +856,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];
@@ -892,6 +892,23 @@ 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, ret = -1;
+
+	for (i=0; ((ret = __psmouse_probe(psmouse)) != 0) && i < 3; i++) {
+		printk(KERN_ERR "psmouse.c: Error encountered while probing"
+			" PS/2 device on %s, reseting.\n", ps2dev->serio->phys);
+		psmouse_reset(psmouse);
+	}
+
+	return ret;
+}
+
+/*
  * Here we set the mouse resolution.
  */