Return to BSD News archive
Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!news.larc.nasa.gov!saimiri.primate.wisc.edu!sdd.hp.com!nigel.msen.com!yale.edu!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: Caps lock keyboard locking....
Message-ID: <1993Mar26.082404.9165@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa.gmd.de
Organization: GMD - German National Research Center for Computer Science
References: <jnpotts.733087223@pv7445.vincent.iastate.edu>
Date: Fri, 26 Mar 1993 08:24:04 GMT
Lines: 30
In article <jnpotts.733087223@pv7445.vincent.iastate.edu>, jnpotts@iastate.edu (James N. Potts) writes:
|> What can be done to stop the keyboard from locking whenever a key such as caps
|> lock, num lock, etc are pressed (besides not pressing them)? Can this be
|> fixed?
|>
|> James
|>
|> --
|> _____________________________________________________________________
|> James N. Potts | "To err is human. To get multiple UAE's
|> jnpotts@iastate.edu | requires MS Windows."
|> tabp6@isuvax.iastate.edu| - Me
This is a race condition in the keyboard/controller. It happens on some
keyboards during processing of the LED switch code. The command to switch the
LEDs is not protected to wait for keyboard ready, and may interfere with the
keyboard interrupt issued for the (CAPS-)key release. A simple, but not
satisfying, fix is to make the update_led routine a NOP.
A real fix requires to pull the LED handling code into the keyboard loop,
similar to the way the Mach kernel handles this.
Holger
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions