Date: Wed, 22 May 1996 15:52:52 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@freebsd.org, j@uriah.heep.sax.de Subject: Re: bad keyboard reset routine? Message-ID: <199605220552.PAA11944@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605220552.PAA11944>