[bisected regression] Touchpad "paste" stops working after suspend to RAM

[bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

Using the latest 2.6.32-rc3+ kernel, the "paste" operation via the 
touchpad of my Vaio laptop does not work after suspend to RAM.

It works flawlessly before s2ram; I select the text with the touchpad
and tap quickly its right corner to paste the selected text.
After a plain 'echo mem > /sys/power/state' the "paste" does not work.

I bisected it to commit ffd0db97196c1057f09c2ab42dd5b30e94e511d9 ("Input: 
add generic suspend and resume for input devices").

I haven't tested if reverting it from mainline fixes the issue, but 
from the patch description I guess that bisection landed correctly
on the culprit.

I have a recent dmesg from my laptop here: 

http://www.aei.mpg.de/~crmafra/dmesg-2.6.32-rc3-wifi.txt

(the wifi warnings there are related to another issue, and the touchpad
problem happens independently of those warnings).

I can test patches and provide more info if necessary.


PS: Due to some HAL configuration issue I have this line in my .bashrc

synclient RTCornerButton=2

which makes the right corner region capable of pasting. When the
kernel is "good", it comes back from resume and I don't need to
run this command again for the 'paste' operation to work. When
the kernel is "bad" running this command has no effect and 
"paste" does not work in any way.

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

Hi Carols,

On Sun, Oct 11, 2009 at 06:21:55PM +0200, Carlos R. Mafra wrote:
> Using the latest 2.6.32-rc3+ kernel, the "paste" operation via the 
> touchpad of my Vaio laptop does not work after suspend to RAM.
> 
> It works flawlessly before s2ram; I select the text with the touchpad
> and tap quickly its right corner to paste the selected text.
> After a plain 'echo mem > /sys/power/state' the "paste" does not work.
> 
> I bisected it to commit ffd0db97196c1057f09c2ab42dd5b30e94e511d9 ("Input: 
> add generic suspend and resume for input devices").
> 
> I haven't tested if reverting it from mainline fixes the issue, but 
> from the patch description I guess that bisection landed correctly
> on the culprit.
> 

Please verify that this is the real offending commit by reverting it - I
am surprised that it would give any trouble since it is supposed to
restore LED state and repeat rate and therefore should only be affecting
keyboards.

-- 
Dmitry

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Sun 11.Oct'09 at 11:01:34 -0700, Dmitry Torokhov wrote:
> Hi Carols,
> 
> On Sun, Oct 11, 2009 at 06:21:55PM +0200, Carlos R. Mafra wrote:
> > Using the latest 2.6.32-rc3+ kernel, the "paste" operation via the 
> > touchpad of my Vaio laptop does not work after suspend to RAM.
> > 
> > It works flawlessly before s2ram; I select the text with the touchpad
> > and tap quickly its right corner to paste the selected text.
> > After a plain 'echo mem > /sys/power/state' the "paste" does not work.
> > 
> > I bisected it to commit ffd0db97196c1057f09c2ab42dd5b30e94e511d9 ("Input: 
> > add generic suspend and resume for input devices").
> > 
> > I haven't tested if reverting it from mainline fixes the issue, but 
> > from the patch description I guess that bisection landed correctly
> > on the culprit.
> > 
> 
> Please verify that this is the real offending commit by reverting it - I
> am surprised that it would give any trouble since it is supposed to
> restore LED state and repeat rate and therefore should only be affecting
> keyboards.

Reverting it fixes the issue, I've just tested it now.

[ I had to edit the resulting drivers/input/input.c because it did not 
  revert cleanly. ]

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

On Sun, Oct 11, 2009 at 09:31:00PM +0200, Carlos R. Mafra wrote:
> On Sun 11.Oct'09 at 11:01:34 -0700, Dmitry Torokhov wrote:
> > Hi Carols,
> > 
> > On Sun, Oct 11, 2009 at 06:21:55PM +0200, Carlos R. Mafra wrote:
> > > Using the latest 2.6.32-rc3+ kernel, the "paste" operation via the 
> > > touchpad of my Vaio laptop does not work after suspend to RAM.
> > > 
> > > It works flawlessly before s2ram; I select the text with the touchpad
> > > and tap quickly its right corner to paste the selected text.
> > > After a plain 'echo mem > /sys/power/state' the "paste" does not work.
> > > 
> > > I bisected it to commit ffd0db97196c1057f09c2ab42dd5b30e94e511d9 ("Input: 
> > > add generic suspend and resume for input devices").
> > > 
> > > I haven't tested if reverting it from mainline fixes the issue, but 
> > > from the patch description I guess that bisection landed correctly
> > > on the culprit.
> > > 
> > 
> > Please verify that this is the real offending commit by reverting it - I
> > am surprised that it would give any trouble since it is supposed to
> > restore LED state and repeat rate and therefore should only be affecting
> > keyboards.
> 
> Reverting it fixes the issue, I've just tested it now.
> 
> [ I had to edit the resulting drivers/input/input.c because it did not 
>   revert cleanly. ]

Carols, I see in the dmesg you supplied earlier ALPS was redetected
successfully, so I guess the problem is that your synclient quirk did
not run after resume. The best way to handle it would be adding a HAL
rule, something like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
        <device>
                <match key="input.x11_driver" contains="synaptics">
                        <merge key="input.x11_options.SHMConfig" type="string">On</merge>
                </match>
        </device>
</deviceinfo>

You'd need to add add the corner tapping command.

Still, I am curious to know why we can't simply reinitialize ALPS from
the get go, could you please send me a dmesg of resume done with
i8042.debug? Thanks!

-- 
Dmitry

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Mon 12.Oct'09 at  2:02:24 -0700, Dmitry Torokhov wrote:
> Carols, I see in the dmesg you supplied earlier ALPS was redetected
> successfully, so I guess the problem is that your synclient quirk did
> not run after resume. 

The basic touchpad stuff works after resume, it is only the right corner 
tap thing which stops working.

> The best way to handle it would be adding a HAL
> rule, something like this:
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <deviceinfo version="0.2">
>         <device>
>                 <match key="input.x11_driver" contains="synaptics">
>                         <merge key="input.x11_options.SHMConfig" type="string">On</merge>
>                 </match>
>         </device>
> </deviceinfo>

This is the scary and ugly thing which I was afraid of originally (it is 
off-topic here, but I don't like HAL). So I have this in my .bashrc 
 
synclient RTCornerButton=2

and so far it worked fine. If possible, I would like to keep it that
way. But I will test the HAL config above too.

> Still, I am curious to know why we can't simply reinitialize ALPS from
> the get go, could you please send me a dmesg of resume done with
> i8042.debug? Thanks!

Yes, I will do it.

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Mon 12.Oct'09 at 11:35:16 +0200, Carlos R. Mafra wrote:
> On Mon 12.Oct'09 at  2:02:24 -0700, Dmitry Torokhov wrote:
> > The best way to handle it would be adding a HAL
> > rule, something like this:
> > 
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <deviceinfo version="0.2">
> >         <device>
> >                 <match key="input.x11_driver" contains="synaptics">
> >                         <merge key="input.x11_options.SHMConfig" type="string">On</merge>
> >                 </match>
> >         </device>
> > </deviceinfo>
> 
> This is the scary and ugly thing which I was afraid of originally (it is 
> off-topic here, but I don't like HAL). So I have this in my .bashrc 
>  
> synclient RTCornerButton=2
> 
> and so far it worked fine. If possible, I would like to keep it that
> way. But I will test the HAL config above too.

I had forgotten that I removed HAL from my Mandriva, so the only solution
for me would be the kernel not regressing.

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Mon 12.Oct'09 at  2:02:24 -0700, Dmitry Torokhov wrote:
> Still, I am curious to know why we can't simply reinitialize ALPS from
> the get go, could you please send me a dmesg of resume done with
> i8042.debug? Thanks!

The dmesg was too big, so I uploaded the ~5000 lines worth of syslog
from 2.6.32-rc4 with i8042.debug info with a suspend to RAM to

http://www.aei.mpg.de/~crmafra/syslog-i8042.debug.txt

I hope this helps!

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

On Mon, Oct 12, 2009 at 12:09:29PM +0200, Carlos R. Mafra wrote:
> On Mon 12.Oct'09 at  2:02:24 -0700, Dmitry Torokhov wrote:
> > Still, I am curious to know why we can't simply reinitialize ALPS from
> > the get go, could you please send me a dmesg of resume done with
> > i8042.debug? Thanks!
> 
> The dmesg was too big, so I uploaded the ~5000 lines worth of syslog
> from 2.6.32-rc4 with i8042.debug info with a suspend to RAM to
> 
> http://www.aei.mpg.de/~crmafra/syslog-i8042.debug.txt
> 
> I hope this helps!

Could you please try this patch and let me know if it helps. Anotehr
i8042.dmesg would be much appreciated.

-- 
Dmitry


Input: psmouse - retry reset command if first one fails

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Sometimes mice are not ready for a command and respond with 0xfe;
failure to reset mouse can lead to losing the device to let's try
harder and repeat the command after delay.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/input/mouse/psmouse-base.c |   13 ++++++++++++-
 drivers/input/serio/libps2.c       |   31 +++++++++++++++++--------------
 2 files changed, 29 insertions(+), 15 deletions(-)


diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
index 690aed9..52ad50f 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -395,8 +395,19 @@ int psmouse_sliced_command(struct psmouse *psmouse, unsigned char command)
 int psmouse_reset(struct psmouse *psmouse)
 {
 	unsigned char param[2];
+	int error;
+
+	error = ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_RESET_BAT);
+	if (error == -EAGAIN) {
+		/*
+		 * Controller requested us to resend the command.
+		 */
+		msleep(100);
+		error = ps2_command(&psmouse->ps2dev,
+				    param, PSMOUSE_CMD_RESET_BAT);
+	}
 
-	if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_RESET_BAT))
+	if (error)
 		return -1;
 
 	if (param[0] != PSMOUSE_RET_BAT && param[1] != PSMOUSE_RET_ID)
diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
index f3876ac..5201b0c 100644
--- a/drivers/input/serio/libps2.c
+++ b/drivers/input/serio/libps2.c
@@ -39,7 +39,7 @@ MODULE_LICENSE("GPL");
 int ps2_sendbyte(struct ps2dev *ps2dev, unsigned char byte, int timeout)
 {
 	serio_pause_rx(ps2dev->serio);
-	ps2dev->nak = 1;
+	ps2dev->nak = ETIME;
 	ps2dev->flags |= PS2_FLAG_ACK;
 	serio_continue_rx(ps2dev->serio);
 
@@ -187,17 +187,17 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
 	int timeout;
 	int send = (command >> 12) & 0xf;
 	int receive = (command >> 8) & 0xf;
-	int rc = -1;
+	int rc;
 	int i;
 
 	if (receive > sizeof(ps2dev->cmdbuf)) {
 		WARN_ON(1);
-		return -1;
+		return -EINVAL;
 	}
 
 	if (send && !param) {
 		WARN_ON(1);
-		return -1;
+		return -EINVAL;
 	}
 
 	serio_pause_rx(ps2dev->serio);
@@ -213,13 +213,16 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
 	 * ACKing the reset command, and so it can take a long
 	 * time before the ACK arrrives.
 	 */
-	if (ps2_sendbyte(ps2dev, command & 0xff,
-			 command == PS2_CMD_RESET_BAT ? 1000 : 200))
+	rc = ps2_sendbyte(ps2dev, command & 0xff,
+			  command == PS2_CMD_RESET_BAT ? 1000 : 200);
+	if (rc)
 		goto out;
 
-	for (i = 0; i < send; i++)
-		if (ps2_sendbyte(ps2dev, param[i], 200))
+	for (i = 0; i < send; i++) {
+		rc = ps2_sendbyte(ps2dev, param[i], 200);
+		if (rc)
 			goto out;
+	}
 
 	/*
 	 * The reset command takes a long time to execute.
@@ -240,10 +243,10 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
 		for (i = 0; i < receive; i++)
 			param[i] = ps2dev->cmdbuf[(receive - 1) - i];
 
-	if (ps2dev->cmdcnt && (command != PS2_CMD_RESET_BAT || ps2dev->cmdcnt != 1))
+	if (ps2dev->cmdcnt && (command != PS2_CMD_RESET_BAT || ps2dev->cmdcnt != 1)) {
+		rc = ETIME;
 		goto out;
-
-	rc = 0;
+	}
 
  out:
 	serio_pause_rx(ps2dev->serio);
@@ -293,13 +296,13 @@ int ps2_handle_ack(struct ps2dev *ps2dev, unsigned char data)
 
 		case PS2_RET_NAK:
 			ps2dev->flags |= PS2_FLAG_NAK;
-			ps2dev->nak = PS2_RET_NAK;
+			ps2dev->nak = EAGAIN;
 			break;
 
 		case PS2_RET_ERR:
 			if (ps2dev->flags & PS2_FLAG_NAK) {
 				ps2dev->flags &= ~PS2_FLAG_NAK;
-				ps2dev->nak = PS2_RET_ERR;
+				ps2dev->nak = EIO;
 				break;
 			}
 
@@ -365,7 +368,7 @@ EXPORT_SYMBOL(ps2_handle_response);
 void ps2_cmd_aborted(struct ps2dev *ps2dev)
 {
 	if (ps2dev->flags & PS2_FLAG_ACK)
-		ps2dev->nak = 1;
+		ps2dev->nak = EIO;
 
 	if (ps2dev->flags & (PS2_FLAG_ACK | PS2_FLAG_CMD))
 		wake_up(&ps2dev->wait);

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Mon 12.Oct'09 at 20:24:14 -0700, Dmitry Torokhov wrote:
> Could you please try this patch and let me know if it helps. 

Yes! The patch quoted below fixed the problem. (and I tested it 
twice already, since I read your suggestion in the other thread :-)

> Anotehr i8042.dmesg would be much appreciated.

Sure, it is here:

http://www.aei.mpg.de/~crmafra/syslog-i8042.debug-patched.txt


> Input: psmouse - retry reset command if first one fails
> 
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> Sometimes mice are not ready for a command and respond with 0xfe;
> failure to reset mouse can lead to losing the device to let's try
> harder and repeat the command after delay.
> 
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> 
>  drivers/input/mouse/psmouse-base.c |   13 ++++++++++++-
>  drivers/input/serio/libps2.c       |   31 +++++++++++++++++--------------
>  2 files changed, 29 insertions(+), 15 deletions(-)
> 
> 
> diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
> index 690aed9..52ad50f 100644
> --- a/drivers/input/mouse/psmouse-base.c
> +++ b/drivers/input/mouse/psmouse-base.c
> @@ -395,8 +395,19 @@ int psmouse_sliced_command(struct psmouse *psmouse, unsigned char command)
>  int psmouse_reset(struct psmouse *psmouse)
>  {
>  	unsigned char param[2];
> +	int error;
> +
> +	error = ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_RESET_BAT);
> +	if (error == -EAGAIN) {
> +		/*
> +		 * Controller requested us to resend the command.
> +		 */
> +		msleep(100);
> +		error = ps2_command(&psmouse->ps2dev,
> +				    param, PSMOUSE_CMD_RESET_BAT);
> +	}
>  
> -	if (ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_RESET_BAT))
> +	if (error)
>  		return -1;
>  
>  	if (param[0] != PSMOUSE_RET_BAT && param[1] != PSMOUSE_RET_ID)
> diff --git a/drivers/input/serio/libps2.c b/drivers/input/serio/libps2.c
> index f3876ac..5201b0c 100644
> --- a/drivers/input/serio/libps2.c
> +++ b/drivers/input/serio/libps2.c
> @@ -39,7 +39,7 @@ MODULE_LICENSE("GPL");
>  int ps2_sendbyte(struct ps2dev *ps2dev, unsigned char byte, int timeout)
>  {
>  	serio_pause_rx(ps2dev->serio);
> -	ps2dev->nak = 1;
> +	ps2dev->nak = ETIME;
>  	ps2dev->flags |= PS2_FLAG_ACK;
>  	serio_continue_rx(ps2dev->serio);
>  
> @@ -187,17 +187,17 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
>  	int timeout;
>  	int send = (command >> 12) & 0xf;
>  	int receive = (command >> 8) & 0xf;
> -	int rc = -1;
> +	int rc;
>  	int i;
>  
>  	if (receive > sizeof(ps2dev->cmdbuf)) {
>  		WARN_ON(1);
> -		return -1;
> +		return -EINVAL;
>  	}
>  
>  	if (send && !param) {
>  		WARN_ON(1);
> -		return -1;
> +		return -EINVAL;
>  	}
>  
>  	serio_pause_rx(ps2dev->serio);
> @@ -213,13 +213,16 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
>  	 * ACKing the reset command, and so it can take a long
>  	 * time before the ACK arrrives.
>  	 */
> -	if (ps2_sendbyte(ps2dev, command & 0xff,
> -			 command == PS2_CMD_RESET_BAT ? 1000 : 200))
> +	rc = ps2_sendbyte(ps2dev, command & 0xff,
> +			  command == PS2_CMD_RESET_BAT ? 1000 : 200);
> +	if (rc)
>  		goto out;
>  
> -	for (i = 0; i < send; i++)
> -		if (ps2_sendbyte(ps2dev, param[i], 200))
> +	for (i = 0; i < send; i++) {
> +		rc = ps2_sendbyte(ps2dev, param[i], 200);
> +		if (rc)
>  			goto out;
> +	}
>  
>  	/*
>  	 * The reset command takes a long time to execute.
> @@ -240,10 +243,10 @@ int __ps2_command(struct ps2dev *ps2dev, unsigned char *param, int command)
>  		for (i = 0; i < receive; i++)
>  			param[i] = ps2dev->cmdbuf[(receive - 1) - i];
>  
> -	if (ps2dev->cmdcnt && (command != PS2_CMD_RESET_BAT || ps2dev->cmdcnt != 1))
> +	if (ps2dev->cmdcnt && (command != PS2_CMD_RESET_BAT || ps2dev->cmdcnt != 1)) {
> +		rc = ETIME;
>  		goto out;
> -
> -	rc = 0;
> +	}
>  
>   out:
>  	serio_pause_rx(ps2dev->serio);
> @@ -293,13 +296,13 @@ int ps2_handle_ack(struct ps2dev *ps2dev, unsigned char data)
>  
>  		case PS2_RET_NAK:
>  			ps2dev->flags |= PS2_FLAG_NAK;
> -			ps2dev->nak = PS2_RET_NAK;
> +			ps2dev->nak = EAGAIN;
>  			break;
>  
>  		case PS2_RET_ERR:
>  			if (ps2dev->flags & PS2_FLAG_NAK) {
>  				ps2dev->flags &= ~PS2_FLAG_NAK;
> -				ps2dev->nak = PS2_RET_ERR;
> +				ps2dev->nak = EIO;
>  				break;
>  			}
>  
> @@ -365,7 +368,7 @@ EXPORT_SYMBOL(ps2_handle_response);
>  void ps2_cmd_aborted(struct ps2dev *ps2dev)
>  {
>  	if (ps2dev->flags & PS2_FLAG_ACK)
> -		ps2dev->nak = 1;
> +		ps2dev->nak = EIO;
>  
>  	if (ps2dev->flags & (PS2_FLAG_ACK | PS2_FLAG_CMD))
>  		wake_up(&ps2dev->wait);

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

[restoring Cc: list]

On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
>
> Could you please try this patch (again if you could post dmesg that
> would be great). Thank you!

The patch quoted below also fixes the problem. I attached the
syslog with i8042.debug (with a s2ram in the middle) to the
bugzilla: 

http://bugzilla.kernel.org/show_bug.cgi?id=14392

(cool! the address above was pasted with the touchpad,
so it is really working :-)

Thanks Dmitry!

> 
> Input: atkbd - postpone restoring LED/repeat rate at resume
> 
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> We need to postpone restoring LED state and typematic settings until
> keyboard is finished reconnecting upon resume. Normally driver core
> and PM infrastructure takes care of proper ordering and dependencies,
> but or case actual reconnect is done asynchronously from kseriod.
> So while driver core thinks that keyboard was resumed and it is time
> to let input core run it's resume handlers in reality keyboard is not
> ready yet. The solution is to keep rescheduling work that adjusts LED
> and rate settings until keyboard is fully enabled.
> 
> Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> 
>  drivers/input/keyboard/atkbd.c |   19 +++++++++++++++----
>  1 files changed, 15 insertions(+), 4 deletions(-)
> 
> 
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index a45157d..022f3cb 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -574,11 +574,22 @@ static void atkbd_event_work(struct work_struct *work)
>  
>  	mutex_lock(&atkbd->event_mutex);
>  
> -	if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
> -		atkbd_set_leds(atkbd);
> +	if (!atkbd->enabled) {
> +		/*
> +		 * Serio ports are resumed asynchronously so while driver core
> +		 * thinks that device is already fully operational in reality
> +		 * it may not be ready yet. In this case we need to keep
> +		 * rescheduling till reconnect completes.
> +		 */
> +		schedule_delayed_work(&atkbd->event_work,
> +					msecs_to_jiffies(100));
> +	} else {
> +		if (test_and_clear_bit(ATKBD_LED_EVENT_BIT, &atkbd->event_mask))
> +			atkbd_set_leds(atkbd);
>  
> -	if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
> -		atkbd_set_repeat_rate(atkbd);
> +		if (test_and_clear_bit(ATKBD_REP_EVENT_BIT, &atkbd->event_mask))
> +			atkbd_set_repeat_rate(atkbd);
> +	}
>  
>  	mutex_unlock(&atkbd->event_mutex);
>  }

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

On Wed, Oct 14, 2009 at 01:16:41AM +0200, Carlos R. Mafra wrote:
> [restoring Cc: list]
> 
> On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
> >
> > Could you please try this patch (again if you could post dmesg that
> > would be great). Thank you!
> 
> The patch quoted below also fixes the problem. I attached the
> syslog with i8042.debug (with a s2ram in the middle) to the
> bugzilla: 
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=14392
> 

Still not quite happy, although it is better. I don't understand why
your box likes to reply on AUX port when command is sent via keyboard
port.

Could you please try booting with atkbd.reset (I assume keyboard is
built in) and send me yet another dmesg.

-- 
Dmitry

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

On Tue, Oct 13, 2009 at 04:56:08PM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 14, 2009 at 01:16:41AM +0200, Carlos R. Mafra wrote:
> > [restoring Cc: list]
> > 
> > On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
> > >
> > > Could you please try this patch (again if you could post dmesg that
> > > would be great). Thank you!
> > 
> > The patch quoted below also fixes the problem. I attached the
> > syslog with i8042.debug (with a s2ram in the middle) to the
> > bugzilla: 
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=14392
> > 
> 
> Still not quite happy, although it is better. I don't understand why
> your box likes to reply on AUX port when command is sent via keyboard
> port.
> 
> Could you please try booting with atkbd.reset (I assume keyboard is
> built in) and send me yet another dmesg.
> 

Oh, yes, keep the last patch applied. Thanks!

-- 
Dmitry

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Tue 13.Oct'09 at 16:57:01 -0700, Dmitry Torokhov wrote:
> On Tue, Oct 13, 2009 at 04:56:08PM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 14, 2009 at 01:16:41AM +0200, Carlos R. Mafra wrote:
> > > [restoring Cc: list]
> > > 
> > > On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
> > > >
> > > > Could you please try this patch (again if you could post dmesg that
> > > > would be great). Thank you!
> > > 
> > > The patch quoted below also fixes the problem. I attached the
> > > syslog with i8042.debug (with a s2ram in the middle) to the
> > > bugzilla: 
> > > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=14392
> > > 
> > 
> > Still not quite happy, although it is better. I don't understand why
> > your box likes to reply on AUX port when command is sent via keyboard
> > port.
> > 
> > Could you please try booting with atkbd.reset (I assume keyboard is
> > built in) and send me yet another dmesg.
> > 
> 
> Oh, yes, keep the last patch applied. Thanks!

I uploaded the dmesg with atkbd.reset (and i8042.debug too, btw)
to the bugzilla.

Thanks for taking care of this, Dmitry!

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

On Wed, Oct 14, 2009 at 02:51:31AM +0200, Carlos R. Mafra wrote:
> On Tue 13.Oct'09 at 16:57:01 -0700, Dmitry Torokhov wrote:
> > On Tue, Oct 13, 2009 at 04:56:08PM -0700, Dmitry Torokhov wrote:
> > > On Wed, Oct 14, 2009 at 01:16:41AM +0200, Carlos R. Mafra wrote:
> > > > [restoring Cc: list]
> > > > 
> > > > On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
> > > > >
> > > > > Could you please try this patch (again if you could post dmesg that
> > > > > would be great). Thank you!
> > > > 
> > > > The patch quoted below also fixes the problem. I attached the
> > > > syslog with i8042.debug (with a s2ram in the middle) to the
> > > > bugzilla: 
> > > > 
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=14392
> > > > 
> > > 
> > > Still not quite happy, although it is better. I don't understand why
> > > your box likes to reply on AUX port when command is sent via keyboard
> > > port.
> > > 
> > > Could you please try booting with atkbd.reset (I assume keyboard is
> > > built in) and send me yet another dmesg.
> > > 
> > 
> > Oh, yes, keep the last patch applied. Thanks!
> 
> I uploaded the dmesg with atkbd.reset (and i8042.debug too, btw)
> to the bugzilla.
> 

Hmm, this is messed up... For some reason your box insists on replying
to reset commands from AUX port, no matter what device we trying to
reset. Does your box (Vaio, right?) has external PS/2 ports? I don't
believe Vaios have docking stations... Also, could you please boot with
i8042.nomux and send me yet another dmesg and dmidecode too.

Thanks for your patience.

-- 
Dmitry

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Tue 13.Oct'09 at 19:30:08 -0700, Dmitry Torokhov wrote:
> On Wed, Oct 14, 2009 at 02:51:31AM +0200, Carlos R. Mafra wrote:
> > On Tue 13.Oct'09 at 16:57:01 -0700, Dmitry Torokhov wrote:
> > > On Tue, Oct 13, 2009 at 04:56:08PM -0700, Dmitry Torokhov wrote:
> > > > On Wed, Oct 14, 2009 at 01:16:41AM +0200, Carlos R. Mafra wrote:
> > > > > [restoring Cc: list]
> > > > > 
> > > > > On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
> > > > > >
> > > > > > Could you please try this patch (again if you could post dmesg that
> > > > > > would be great). Thank you!
> > > > > 
> > > > > The patch quoted below also fixes the problem. I attached the
> > > > > syslog with i8042.debug (with a s2ram in the middle) to the
> > > > > bugzilla: 
> > > > > 
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=14392
> > > > > 
> > > > 
> > > > Still not quite happy, although it is better. I don't understand why
> > > > your box likes to reply on AUX port when command is sent via keyboard
> > > > port.
> > > > 
> > > > Could you please try booting with atkbd.reset (I assume keyboard is
> > > > built in) and send me yet another dmesg.
> > > > 
> > > 
> > > Oh, yes, keep the last patch applied. Thanks!
> > 
> > I uploaded the dmesg with atkbd.reset (and i8042.debug too, btw)
> > to the bugzilla.
> > 
> 
> Hmm, this is messed up... For some reason your box insists on replying
> to reset commands from AUX port, no matter what device we trying to
> reset. Does your box (Vaio, right?) has external PS/2 ports? I don't
> believe Vaios have docking stations... 

My Vaio has no PS/2 port and no docking station.

> Also, could you please boot with
> i8042.nomux and send me yet another dmesg and dmidecode too.

Ok, they are in the kernel bugzilla #14392 now.

> Thanks for your patience.

I thank _you_ for digging the problem even further. Your proposed patch
"fixed" it already for me, but you are being honest in saying that
you are still not happy with your fix and want to do better. I really
appreciate that and will help you with what I can do. I hope there is
a way out of my Vaio's oddities.

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Dmitry Torokhov]

On Wed, Oct 14, 2009 at 01:13:25PM +0200, Carlos R. Mafra wrote:
> On Tue 13.Oct'09 at 19:30:08 -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 14, 2009 at 02:51:31AM +0200, Carlos R. Mafra wrote:
> > > On Tue 13.Oct'09 at 16:57:01 -0700, Dmitry Torokhov wrote:
> > > > On Tue, Oct 13, 2009 at 04:56:08PM -0700, Dmitry Torokhov wrote:
> > > > > On Wed, Oct 14, 2009 at 01:16:41AM +0200, Carlos R. Mafra wrote:
> > > > > > [restoring Cc: list]
> > > > > > 
> > > > > > On Tue 13.Oct'09 at 13:24:59 -0700, Dmitry Torokhov wrote:
> > > > > > >
> > > > > > > Could you please try this patch (again if you could post dmesg that
> > > > > > > would be great). Thank you!
> > > > > > 
> > > > > > The patch quoted below also fixes the problem. I attached the
> > > > > > syslog with i8042.debug (with a s2ram in the middle) to the
> > > > > > bugzilla: 
> > > > > > 
> > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=14392
> > > > > > 
> > > > > 
> > > > > Still not quite happy, although it is better. I don't understand why
> > > > > your box likes to reply on AUX port when command is sent via keyboard
> > > > > port.
> > > > > 
> > > > > Could you please try booting with atkbd.reset (I assume keyboard is
> > > > > built in) and send me yet another dmesg.
> > > > > 
> > > > 
> > > > Oh, yes, keep the last patch applied. Thanks!
> > > 
> > > I uploaded the dmesg with atkbd.reset (and i8042.debug too, btw)
> > > to the bugzilla.
> > > 
> > 
> > Hmm, this is messed up... For some reason your box insists on replying
> > to reset commands from AUX port, no matter what device we trying to
> > reset. Does your box (Vaio, right?) has external PS/2 ports? I don't
> > believe Vaios have docking stations... 
> 
> My Vaio has no PS/2 port and no docking station.
> 
> > Also, could you please boot with
> > i8042.nomux and send me yet another dmesg and dmidecode too.
> 
> Ok, they are in the kernel bugzilla #14392 now.
> 
> > Thanks for your patience.
> 
> I thank _you_ for digging the problem even further. Your proposed patch
> "fixed" it already for me, but you are being honest in saying that
> you are still not happy with your fix and want to do better. I really
> appreciate that and will help you with what I can do. I hope there is
> a way out of my Vaio's oddities.

Ok, so here is hopefullt the last patch, it automatically disables MUX
mode on your Vaio since it is broken (you still need the previous patch
that changes atkbd since - there are 2 diffrent issues). I'd appreciate
if you could test it - if it works then you should see mention of only 2
serio ports in your dmesg and not 5.

Thanks!

-- 
Dmitry


Input: i8042 - add Sony Vaio VGN-FZ240E to the nomux list

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

On this model, when KBD is in active multiplexing mode, acknowledgements
to reset and get ID commands issued on KBD port sometimes are delivered
to AUX3 port (touchpad) which messes up device detection. Legacy KBC
mode works fine and since there are no external PS/2 ports on this laptop
and no support for docking station we can safely disable active MUX mode.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/input/serio/i8042-x86ia64io.h |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)


diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index 77ff205..a537925 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -327,6 +327,17 @@ static struct dmi_system_id __initdata i8042_dmi_nomux_table[] = {
 		},
 	},
 	{
+		/*
+		 * Reset and GET ID commands issued via KBD port are
+		 * sometimes being delivered to AUX3.
+		 */
+		.ident = "Sony Vaio FZ-240E",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "VGN-FZ240E"),
+		},
+	},
+	{
 		.ident = "Amoi M636/A737",
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "Amoi Electronics CO.,LTD."),

Re: [bisected regression] Touchpad "paste" stops working after suspend to RAM

[Carlos R. Mafra]

On Wed 14.Oct'09 at 17:44:52 -0700, Dmitry Torokhov wrote:
> Ok, so here is hopefullt the last patch, it automatically disables MUX
> mode on your Vaio since it is broken (you still need the previous patch
> that changes atkbd since - there are 2 diffrent issues). I'd appreciate
> if you could test it 

I tested the patch below on top of the atkbd patch, and paste still
works after s2ram

> - if it works then you should see mention of only 2
> serio ports in your dmesg and not 5.

And now I see this in the dmesg

PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice

so your patch did what you said it would.

Thanks Dmitry!


> Input: i8042 - add Sony Vaio VGN-FZ240E to the nomux list
> 
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> On this model, when KBD is in active multiplexing mode, acknowledgements
> to reset and get ID commands issued on KBD port sometimes are delivered
> to AUX3 port (touchpad) which messes up device detection. Legacy KBC
> mode works fine and since there are no external PS/2 ports on this laptop
> and no support for docking station we can safely disable active MUX mode.
> 
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> 
>  drivers/input/serio/i8042-x86ia64io.h |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
> index 77ff205..a537925 100644
> --- a/drivers/input/serio/i8042-x86ia64io.h
> +++ b/drivers/input/serio/i8042-x86ia64io.h
> @@ -327,6 +327,17 @@ static struct dmi_system_id __initdata i8042_dmi_nomux_table[] = {
>  		},
>  	},
>  	{
> +		/*
> +		 * Reset and GET ID commands issued via KBD port are
> +		 * sometimes being delivered to AUX3.
> +		 */
> +		.ident = "Sony Vaio FZ-240E",
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
> +			DMI_MATCH(DMI_PRODUCT_NAME, "VGN-FZ240E"),
> +		},
> +	},
> +	{
>  		.ident = "Amoi M636/A737",
>  		.matches = {
>  			DMI_MATCH(DMI_SYS_VENDOR, "Amoi Electronics CO.,LTD."),