From owner-freebsd-current  Tue May 21 23:01:11 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA19467
          for current-outgoing; Tue, 21 May 1996 23:01:11 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA19460
          for <freebsd-current@freebsd.org>; Tue, 21 May 1996 23:01:06 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA11944; Wed, 22 May 1996 15:52:52 +1000
Date: Wed, 22 May 1996 15:52:52 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199605220552.PAA11944@godzilla.zeta.org.au>
To: freebsd-current@freebsd.org, j@uriah.heep.sax.de
Subject: Re: bad keyboard reset routine?
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> Thanks for reminding me..  I also meant to mention that I've been
>> getting:
>> 
>> scprobe: keyboard RESET failed (result = 0xfa)

This has only been reported about 10 times before :-).  Philippe Charnier
reported that the total delay needs to be at least 250 msec.  It isn't
clear whether this is caused by a strange keyboard or one of the software
bugs.  My keyboards take 3-5ms to return each of the reset response code.s

>I vote for killing scprobe()'s keyboard reset attempt entirely.  It's
>of no real use.

It is used to set the keyboard to a known state.  E.g., it blows away the
BIOS defaults for the keyboard repeat and delay rates (RAD), and it turns
the keyboard LEDs off.  Syscons doesn't track the RAD state, and scattach()
calls update_leds(), and update_leds() sets the LEDs unconditionally, so
it isn't essential to set the RAD and LEDs to a known state, but I think
the keyboard should be reset just to reduce complications.  There are
more complications if the kernel is booted with -d.  scinit() doesn't
sync the physical LED state with the syscons variable for the LED state.
It syncs the BIOS number-lock state with the syscons variable, but it
doesn't sync the other BIOS lock-key states, so it is possible for the
LEDs not to match the actual state.

Bruce