> On Sun, Jul 14, 2002 at 02:37:02PM +0200, Vojtech Pavlik wrote:
>
> >>>> atkbd.c: Sent: f5
> >>>> atkbd.c: Received fe
>
> >>> Ok. So this is the cause. The driver gets a '0xfe' response, which means
> >>> "error, command not supported, or device not present'.
>
> >> In principle nothing is wrong when one gets a 0xfe.
> >> The request is just: please say that again.
>
> > 0xfe
> > Resend. Keyboard will send this if it didn't receive the last command
> > correctly.
> >
> > Unfortunately, 0xfe also happens when you send a command to a keyboard
> > that's not plugged, or when the keyboard doesn't understand the command.
> > Resending in those cases (which are the most common) would cause an
> > infinite loop ...
>
> Not so pessimistic. The first resend may be needed because the keyboard
> does not stabilize so quickly after power on.
> You wait 25 ms and try again. Wait 500 ms and try again. Give up.
>
> But if this is really the first command sent to the keyboard, then
> I think 0xf5 is uncommon.
>
> One usually sees a sequence like:
> Send 0xaa to port 64. Wait for the 0x55 ack.
> Do things to enable A20, IRQ1, set scancode translation.
> Send 0xff to port 60. Wait for the 0xfa ack. Wait for the 0xaa good status.
The problem is that 0xff takes too long to finish to be done while Linux
is booting, and it has already been done by the BIOS.
> When 0xf5 fails, one might consider trying a more standard sequence.
-- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/