Reset ps/2 port should psmouse_probe fail before retrying

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.

Am Freitag, den 16.04.2010, 18:52 -0400 schrieb Peter M. Petrakis:

Quoted 9 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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?

Hi

Am Samstag, den 17.04.2010, 11:31 -0400 schrieb Peter M. Petrakis:

Quoted 6 lines

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.

Quoted 2 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hi Peter,

does this work for you?

I8042_CMD_AUX_ENABLE gets now triggered during pm_restore.

drivers/input/serio/i8042.c +3 -2

index 6440a8f..1af5a58 100644
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

Quoted 3 lines · 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.

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?

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.

Quoted 5 lines · 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

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

Quoted 6 lines

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

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.

Quoted 2 lines · Peter M. Petrakis

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.

Quoted 2 lines

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.

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?

drivers/input/mouse/psmouse-base.c +7 -3

index d8c0c8d..6877371 100644
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

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.

Quoted 8 lines

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.

Quoted 5 lines

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?

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 18 lines · Christoph Fritz

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 7 lines

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?

Quoted 4 lines

[    8.239494] input: PS/2 Synaptics TouchPad as

/devices/platform/i8042/serio1/input/input12

Quoted 8 lines

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.

Quoted 4 lines · Christoph Fritz

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.

Quoted 7 lines · Dmitry Torokhov

Quoted 4 lines · Christoph Fritz

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.

Quoted 4 lines

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.

Quoted 8 lines · Christoph Fritz

Quoted 7 lines · Dmitry Torokhov

Quoted 4 lines · Christoph Fritz

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.

Quoted 6 lines

Quoted 4 lines

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

---
 drivers/input/mouse/psmouse-base.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

drivers/input/mouse/psmouse-base.c +0 -0

index d8c0c8d..66ce0ac 100644

drivers/input/mouse/psmouse-base.c +3 -2

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

Here are the dmesg boot logs with i8042.debug.

Quoted 30 lines · Dmitry Torokhov

Quoted 18 lines · Christoph Fritz

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 7 lines

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?

Quoted 33 lines · Peter M. Petrakis

Here are the dmesg boot logs with i8042.debug.

Quoted 30 lines · Dmitry Torokhov

Quoted 18 lines · Christoph Fritz

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 7 lines

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,

This Dell in question do not have an option to disable the touchpad. The BIOS options are unremarkable.

Peter

Quoted 37 lines · Dmitry Torokhov

Quoted 33 lines · Peter M. Petrakis

Here are the dmesg boot logs with i8042.debug.

Quoted 30 lines · Dmitry Torokhov

Quoted 18 lines · Christoph Fritz

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 7 lines

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.

Quoted 43 lines · Peter M. Petrakis

Dmitry,

This Dell in question do not have an option to disable the touchpad. The BIOS options are unremarkable.

Peter

Quoted 35 lines · Dmitry Torokhov

Quoted 33 lines · Peter M. Petrakis

Here are the dmesg boot logs with i8042.debug.

Quoted 30 lines · Dmitry Torokhov

Quoted 18 lines · Christoph Fritz

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 8 lines

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?

Quoted 2 lines

Quoted 2 lines

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

Quoted 45 lines · Peter M. Petrakis

Dmitry,

This Dell in question do not have an option to disable the touchpad. The BIOS options are unremarkable.

Peter

Quoted 37 lines · Dmitry Torokhov

Quoted 33 lines · Peter M. Petrakis

Here are the dmesg boot logs with i8042.debug.

Quoted 30 lines · Dmitry Torokhov

Quoted 18 lines · Christoph Fritz

Am Donnerstag, den 22.04.2010, 14:55 -0700 schrieb Dmitry Torokhov:

Quoted 9 lines · Peter M. Petrakis

Quoted 8 lines

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.

Quoted 7 lines

Quoted 4 lines

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?

Quoted 7 lines

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?

drivers/input/mouse/synaptics.c +6 -3

index 026df60..aa25fbd 100644
@@ -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

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.

Am Freitag, den 30.04.2010, 18:37 -0400 schrieb Peter M. Petrakis:

Quoted 5 lines

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:

drivers/input/mouse/psmouse-base.c +9 -6

index d8c0c8d..5e726df 100644
@@ -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,

drivers/input/mouse/psmouse.h +3 -0

index e053bdd..c45b5ef 100644
@@ -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,

Am Freitag, den 30.04.2010, 18:37 -0400 schrieb Peter M. Petrakis:

Quoted 5 lines

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:

drivers/input/mouse/psmouse-base.c +9 -6

index d8c0c8d..5e726df 100644
@@ -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,

drivers/input/mouse/psmouse.h +3 -0

index e053bdd..c45b5ef 100644
@@ -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,

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.

What about simply resetting the mouse before actually trying to reconnect?

Quoted 2 lines · Dmitry Torokhov

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

Quoted 6 lines · Christoph Fritz

Quoted 2 lines · Dmitry Torokhov

What about simply resetting the mouse before actually trying to reconnect?

Isn't psmouse_reconnect() the first in psmouse-base.c that gets

called

Quoted 2 lines

after waking up from hibernation/suspend?
And should all ps2 devices get a reset or only the one which needs

it

Quoted 2 lines

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

Signature · 19 lines

Dmitry

Input: psmouse - reset all types of mice before reconnecting

From: Dmitry Torokhov <[email protected]>

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

 drivers/input/mouse/psmouse-base.c |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

drivers/input/mouse/psmouse-base.c +1 -0

index cbc8072..a3c9731 100644
@@ -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) {

drivers/input/mouse/psmouse-base.c +9 -4

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