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

[Vojtech Pavlik <vojtech@suse.cz>]

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