[PATCH 24/44] Workaround i8042 chips with broken MUX mode

[PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Vojtech Pavlik]

You can pull this changeset from:
	bk://kernel.bkbits.net/vojtech/input

===================================================================

ChangeSet@1.1608.56.2, 2004-03-03 11:49:20+01:00, vojtech@suse.cz
  input: Workaround i8042 chips with broken MUX mode.


 i8042.c |    5 +++++
 1 files changed, 5 insertions(+)

===================================================================

diff -Nru a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
--- a/drivers/input/serio/i8042.c	Tue Mar 16 13:18:37 2004
+++ b/drivers/input/serio/i8042.c	Tue Mar 16 13:18:37 2004
@@ -530,6 +530,11 @@
 
 	if (i8042_enable_mux_mode(values, &mux_version))
 		return -1;
+	
+	/* Workaround for broken chips which seem to support MUX, but in reality don't. */
+	/* They all report version 12.10 */
+	if (mux_version == 0xCA)
+		return -1;
 
 	printk(KERN_INFO "i8042.c: Detected active multiplexing controller, rev %d.%d.\n",
 		(mux_version >> 4) & 0xf, mux_version & 0xf);

RE: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Dmitry Torokhov]

Vojtech Pavlik wrote:
> +	
> +	/* Workaround for broken chips which seem to
support MUX, but in reality don't. */
> +	/* They all report version 12.10 */
> +	if (mux_version == 0xCA)
> +		return -1;

Hi, 

I think it should be 0xAC (0xA4 with 4th bit flipped)
as the version reported is 10.12:

i8042.c: Detected active multiplexing controller, rev
10.12.

>From little debug info that I've been sent ThinkPad's
controllers seem to be flipping 4th bit sometimes, I
can't quite pinpoint the exact sequence.

Dmitry

P.S. Sorry for breaking the threading...

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Vojtech Pavlik]

On Tue, Mar 16, 2004 at 10:24:09AM -0800, Dmitry Torokhov wrote:

> Vojtech Pavlik wrote:
> > +	
> > +	/* Workaround for broken chips which seem to
> support MUX, but in reality don't. */
> > +	/* They all report version 12.10 */
> > +	if (mux_version == 0xCA)
> > +		return -1;
> 
> Hi, 
> 
> I think it should be 0xAC (0xA4 with 4th bit flipped)
> as the version reported is 10.12:
> 
> i8042.c: Detected active multiplexing controller, rev
> 10.12.
> 
> From little debug info that I've been sent ThinkPad's
> controllers seem to be flipping 4th bit sometimes, I
> can't quite pinpoint the exact sequence.

Could this be the bit that indicates whether the report is coming from
an internal or external device?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Vojtech Pavlik]

On Tue, Mar 16, 2004 at 10:24:09AM -0800, Dmitry Torokhov wrote:
> Vojtech Pavlik wrote:
> > +	
> > +	/* Workaround for broken chips which seem to
> support MUX, but in reality don't. */
> > +	/* They all report version 12.10 */
> > +	if (mux_version == 0xCA)
> > +		return -1;
> 
> Hi, 
> 
> I think it should be 0xAC (0xA4 with 4th bit flipped)
> as the version reported is 10.12:
> 
> i8042.c: Detected active multiplexing controller, rev
> 10.12.
> 
> From little debug info that I've been sent ThinkPad's
> controllers seem to be flipping 4th bit sometimes, I
> can't quite pinpoint the exact sequence.

Thanks, fixed.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Vojtech Pavlik]

On Fri, Mar 19, 2004 at 12:05:36AM -0500, Dmitry Torokhov wrote:

> > Could this be the bit that indicates whether the report is coming from
> > an internal or external device?
> 
> That is what I suspect, but I can not prove it and in fact I am quite
> surprised that KBC would mangle data requested via CMD_AUX_LOOP. So far
> I have seen the following sequences (* denotes 4th bit flipped):
> 
> 2.6.1:
> IN:    	FO   
> OUT:    F8* 
> 
> 2.6.2-rc1-bk1:
> IN:     5A  F0  56  A4 
> OUT:    5A  F0  56  AC*
> 
> 2.6.3 + my debug
> IN:     5A  A4  5B  A4  53  F0  56
> OUT:    5A  A4  5B  AC* AC  F0  5E*
> 
> 2.6.3 + my other debug
> IN:     5A  A4  A4  A4  A4  F0  56  A4  A4  A4  A4
> OUT:	5A  A4  A4  A4  A4  F0  56  A4  A4  A4  A4
> 
> ... and I am waiting on sequence:
> 5A 00 00 00 00 F0 56 A4 00 00 00 00
> 
> As you can see it does not always flip that bit, but if it will mangle the
> last sequence I think we can claim that we see "hidden multiplexor" and
> abort active multiplexor test.

So far on every machine I've got a report from it was caused by BIOS
emulation of PS/2 mouse using an USB mouse (even when USB mouse wasn't
present). Compiling the USB modules into the kernel fixes the problem.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Stefan Smietanowski]

Hi.

> So far on every machine I've got a report from it was caused by BIOS
> emulation of PS/2 mouse using an USB mouse (even when USB mouse wasn't
> present). Compiling the USB modules into the kernel fixes the problem.

Could this have anything to do with the fact that my x86-64 kernel nukes
on startup if USB keyboard/mouse emul is enabled in the BIOS?

This is on an ASUS K8T800 and an MSI K8T800 board.

If you don't know what I'm talking about I'll give more info of course.

// Stefan

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Vojtech Pavlik]

On Fri, Mar 19, 2004 at 03:21:27PM +0100, Stefan Smietanowski wrote:
> Hi.
> 
> >So far on every machine I've got a report from it was caused by BIOS
> >emulation of PS/2 mouse using an USB mouse (even when USB mouse wasn't
> >present). Compiling the USB modules into the kernel fixes the problem.
> 
> Could this have anything to do with the fact that my x86-64 kernel nukes
> on startup if USB keyboard/mouse emul is enabled in the BIOS?

Yes, and no. USB keyboard/mouse emulation is simply broken in most
BIOSes. It's even more broken on AMD64 BIOSes, because usually noone
tests its interaction with 64-bit longmode. And thus when it is invoked
in 64-bit longmode, it crashes the machine.

On x86 it just causes problems with PS/2 mouse and keyboard.

So it's caused by the same thing, but these are two different problems.

> This is on an ASUS K8T800 and an MSI K8T800 board.
> 
> If you don't know what I'm talking about I'll give more info of course.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Andries Brouwer]

On Tue, Mar 16, 2004 at 10:24:09AM -0800, Dmitry Torokhov wrote:
> Vojtech Pavlik wrote:

> > +	/* Workaround for broken chips which seem to
> support MUX, but in reality don't. */

Why call them "broken"? Better to delete that word.

> > +	/* They all report version 12.10 */
> > +	if (mux_version == 0xCA)
> > +		return -1;
> 
> I think it should be 0xAC (0xA4 with 4th bit flipped)
> as the version reported is 10.12.

Yes. I have seen one such report. Have there been more?

The Synaptics multiplexing proposal uses 0xf0, 0x56, 0xa4
to activate and 0xf0, 0x56, 0xa5 to deactivate.
In both cases the replies must be 0xf0, 0x56, version.

Thus, I suppose one might get a more robust detection
by checking that both the activation and deactivation
sequences yield the same version.

Andries

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Dmitry Torokhov]

On Saturday 27 March 2004 07:29 pm, Andries Brouwer wrote:
> On Tue, Mar 16, 2004 at 10:24:09AM -0800, Dmitry Torokhov wrote:
> > Vojtech Pavlik wrote:
> 
> > > +	/* Workaround for broken chips which seem to
> > support MUX, but in reality don't. */
> 
> Why call them "broken"? Better to delete that word.
> 
> > > +	/* They all report version 12.10 */
> > > +	if (mux_version == 0xCA)
> > > +		return -1;
> > 
> > I think it should be 0xAC (0xA4 with 4th bit flipped)
> > as the version reported is 10.12.
> 
> Yes. I have seen one such report. Have there been more?
>

As it turned out its not the chip but USB legacy emulation that
gets in the way of synaptics query. Actually alot of problems were
linked to broken legacy emulation implementations, Vojtech mentioned
that PCI quirk to turn legacy emulation off may be appropriate.
 
> The Synaptics multiplexing proposal uses 0xf0, 0x56, 0xa4
> to activate and 0xf0, 0x56, 0xa5 to deactivate.
> In both cases the replies must be 0xf0, 0x56, version.
> 
> Thus, I suppose one might get a more robust detection
> by checking that both the activation and deactivation
> sequences yield the same version.
>

Unfortunately in this particular case it looks like something flips
4th bit on some (but not all, like every 3rd) bytes, so it may very
well respond with 0xAC to both queries.
  
-- 
Dmitry

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Andries Brouwer]

On Sat, Mar 27, 2004 at 07:40:39PM -0500, Dmitry Torokhov wrote:

> > The Synaptics multiplexing proposal uses 0xf0, 0x56, 0xa4
> > to activate and 0xf0, 0x56, 0xa5 to deactivate.
> > In both cases the replies must be 0xf0, 0x56, version.
> > 
> > Thus, I suppose one might get a more robust detection
> > by checking that both the activation and deactivation
> > sequences yield the same version.
> >
> 
> Unfortunately in this particular case it looks like something flips
> 4th bit on some (but not all, like every 3rd) bytes, so it may very
> well respond with 0xAC to both queries.

If one flips that bit on 0xa5 the result is 0xad, not 0xac.

That the bit is set is not strange.
The standard PS/2 protocol requires bit 3 in the first word of
every 3-byte packet to be 1.

Andries

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Dmitry Torokhov]

On Saturday 27 March 2004 08:25 pm, Andries Brouwer wrote:
> On Sat, Mar 27, 2004 at 07:40:39PM -0500, Dmitry Torokhov wrote:
> 
> > > The Synaptics multiplexing proposal uses 0xf0, 0x56, 0xa4
> > > to activate and 0xf0, 0x56, 0xa5 to deactivate.
> > > In both cases the replies must be 0xf0, 0x56, version.
> > > 
> > > Thus, I suppose one might get a more robust detection
> > > by checking that both the activation and deactivation
> > > sequences yield the same version.
> > >
> > 
> > Unfortunately in this particular case it looks like something flips
> > 4th bit on some (but not all, like every 3rd) bytes, so it may very
> > well respond with 0xAC to both queries.
> 
> If one flips that bit on 0xa5 the result is 0xad, not 0xac.

Yes, you are right.

> 
> That the bit is set is not strange.
> The standard PS/2 protocol requires bit 3 in the first word of
> every 3-byte packet to be 1.

If it did it in every 3rd byte and not in response to loopback requiest
but to real data stream coming from a device I would agree...

-- 
Dmitry

Re: [PATCH 24/44] Workaround i8042 chips with broken MUX mode

[Stefan Smietanowski]

Hi.

> linked to broken legacy emulation implementations, Vojtech mentioned
> that PCI quirk to turn legacy emulation off may be appropriate.

Is there any code available that can do that as it is now?

This would be useful especially right now under x86-64.

As it is right now I either have the keyboard plugged into
both ps/2 and usb, plug it in only into usb (can't operate
grub) or plug it only into usb (enable emulation, can't
run linux ... ) and if the kernel could have a way of
disabling the emulation that would be good at least in
my case.

// Stefan