## Input/Output Device Driver Reference

[prev][next][parent][TOC]

### The Device-Dependent Driver

The device-dependent driver uses a state machine to control the hardware interrupts. The following is a diagram of the state machine:

[Artwork not shown]

NOCMDIPG (No Command In Progress (*)) This is the base state. It accepts scan codes as keystrokes and it passes them in a key packet to the DI driver. It also checks for an override (FFh) scan code. This is usually the start of a hot plug sequence; therefore, move to the [HOTPLGPG] state.

RCVDE0SC (Received E0h Scan Code (*)) If [NOCMDIPG] receives an E0h scan code, it jumps to this state to await the remaining keystroke scan byte. These two bytes are then passed to the DI driver in a key packet. Upon completion, return to the state [NOCMDIPG].

HOTPLGPG (Notify Hot-Plug in Progress) If [NOCMDIPG] receives FFh, it jumps to this state and waits for the next scan code. If the next scan code is an AAh, it starts the hot plug sequence. If not, then it beeps the keyboard and returns to [NOCMDIPG] state to pass the scan code to the DI driver.

SENTLEDC (Sent LED Command (!)) The change LEDs command has been sent to the keyboard and is now awaiting an ACK from the keyboard. When one is received, send the new LED data byte to the keyboard and go to [SENTLEDD] to wait for an ACK.

SENTLEDD (Sent LED Data (!)) The LED byte is sent to the keyboard and is awaiting an ACK. When one is received, go to [NOCMDIPG] and wait for the next scan code.

SENTTYPC (Sent Typematic Command (!)) The change type rate/delay command has been sent to the keyboard, and is now awaiting an ACK from the keyboard . When one is received, send the new type rate/delay data byte to the keyboard and go to [SENTTYPD] to wait for an ACK.

SENTTYPD (Sent Typematic Rate (!)) The new type rate/delay byte has been sent to the keyboard and is awaiting an ACK. When one is received, go to [NOCMDIPG] and wait for the next scan code.

SENTIDCM (Sent Read ID Command) The Read ID command has been sent to the keyboard, and is now awaiting an ACK from the keyboard. When one is received, start a timer and go to [WAITIDB1] to await the first ID byte (go to [GTKBDCMD] upon timeout).

WAITIDB1 (Wait for First ID Byte) The Read ID command has been sent and ACK has been received. The device driver is waiting for the first ID byte. When one is received, go to [WAITIDB2] to await the second ID byte.

WAITIDB2 (Wait for Second ID Byte) The first ID byte has been received, and the driver is now waiting for the second ID byte. When the byte has been received, request the controller command byte and go to [GTKBDCMD].

GTKBDCMD (Get Controller Command Byte(!)) The device driver waits for the command byte from the keyboard controller. If the Scan-Code Set is set to 1 , then the driver makes the request to change the Scan-Code Set. If the Scan-Code Set is set to 2, then the driver goes to [SENTSCSC].

SENTSCSC (Sent Out Scan-Code Set Change(!)) When the device driver receives an ACK, it sends out the correct Scan-Code Set to the keyboard and then goes to [SENTSCSD] to wait for an ACK.

SENTSCSD (Sent Out Correct Scan-Code Set(!)) The device driver is waiting for an ACK from the keyboard to acknowledge that it has completed the request. To ensure that the type rate/delay is correct, send off the change type rate/delay command and go to [SENTTYPC].

Note: The state sequence from SENTIDCM to SENTSCSD should only occur during init and after every Hot Plug as it is part of the setup routine.

(*) This state generates a keystroke packet.
(!) This state starts a timer that resets the state machine and flags an error, if time runs out.