General Input Device Emulating Interface

(GIDEI) Standard

Version 2.1

Copyright (c) 1994, 2011 Trace R&D Center
University of Wisconsin
2107 Engineering Centers Bldg.
1550 Engineering Dr.
Madison, WI 53706
Reproduction With Permission Only

Please send any comments regarding this proposal to:

Standards Project Manager
Trace Research and Development Center, University of Wisconsin
2107 Engineering Centers Bldg., 1550 Engineering Dr., Madison, WI 53719


Table of Contents

GIDEI Introduction.

GIDEI Purpose.

GIDEI Overview.

GIDEI Commands At A Glance.

Miscellaneous Command(s) .

Definition of Terms.

Hardware Connection.

Character Mode.
Escape Sequence Mode.
Miscellaneous Escape Sequence Commands.
Keyboard Escape Sequence Commands.
Mouse Escape Sequence Commands.
GIDEI Key Name Aliases.

Appendix A.

GIDEI Introduction

The General Input Device Emulating Interface (GIDEI) Proposal defines a connection and data communication protocol between alternate input devices (e.g., augmentative and alternative communication [AAC] devices) and interfaces which emulate standard computer input devices.

There are a number alternate input or AAC devices capable of emulating the standard computer input devices. However, computers as they are currently designed cannot understand the output from an AAC device without some kind of communication translation taking place. This communication translation is usually accomplished by the emulating interface. The emulating interface can be a hardware device (e.g., Trace Transparent Access Module) or special software running on a computer (e.g., "SerialKeys" feature of AccessDOS) that converts the characters and commands transmitted over the serial cable from the alternate input device into keystroke and mouse actions understood by the receiving computer. In either case, a hardware interface (e.g. a serial port) is necessary to supply or support the connection from the alternate input device to the emulating interface. The hardware interface (e.g., a serial port) can be physically located on an external hardware device attached to the computer or be part of the computer itself.

As you read or refer to this GIDEI Proposal, you will need to distinguish between what the GIDEI Proposal is defining (e.g., the connection and data communication protocol) and what other pieces are necessary to allow alternative input or AAC devices to function as computer input devices (e.g., keyboards, mice, etc.).

For a quick reference, several of the GIDEI commands which comprise the "data communication protocol" are listed in the section titled "GIDEI Commands At A Glance." Information concerning the GIDEI "connection protocol" requirements are covered later in this document in the section titled "Hardware Connection."

In addition, Appendix A has added information on an industry wide effort that promises to make PC installation and use easier for all computer users. Collectively known as the External COM device "Plug- and-Play" draft specification, it is an attempt to simplify the installation, device identification, and initial communication for devices attaching on the "serial" port, which may have a far reaching effort towards "ease-of-use" for AAC devices accessing a computer via GIDEI.

GIDEI Purpose

The main purpose of the GIDEI Proposal is to provide developers of AAC and other alternate input devices with a viable approach that enables them to use their devices as replacements for the normal keyboard and mouse on general purpose computers. This allows people who are "unable" to effectively operate the normal keyboard and mouse, to access computer systems and software from their alternate input device.

Keep in mind that the General Input Device Emulating Interface (GIDEI) Proposal defines a connection and data communication protocol only, between the alternate input devices and other emulating interfaces which emulate standard computer input devices, not to any software or hardware designed to do translation.

Background

A person who is unable to access a computer is at a great disadvantage in today's society. Many schools and jobs require the use of computers daily. The person who is physically unable to use a computer keyboard or mouse can not participate in certain activities on an equal level with others.

Technology has evolved to the point where electronic aids are available for many people with physical disabilities to assist them in doing many of the same things that others are doing on standard computer systems. For example, several aids can perform word processing features. Yet there still exists the need to access the same computers and software that are used by others. In schools and in the workplace, an individual is often required to use the same software programs that others are using.

Fortunately, many special electronic aids used by people with disabilities can be used as alternate input devices for standard computers. Any device which is capable of connecting to a computer as described in this GIDEI Proposal and also capable of transmitting ASCII information arranged to conform with the GIDEI data communication protocol, should be capable of acting as a alternate input device.

The following figures should help you to better understand the terminologies GIDEI, alternate input device, and emulating interface. Each figure contains a picture of a computer, showing the connection for the standard keyboard and mouse input devices. Each figure also contains a picture of a alternative input device (e.g., AAC) device that is also connected in some fashion to the computer. It is this AAC device-to- computer connection that is the critical component you need to understand, when determining if you need-to- follow the GIDEI Proposal for connection and data communication purposes between your AAC device and the computer.

The detailed discussions which follow are designed to assist you in better understanding the proper application of the GIDEI Proposal, with or without the figures as a reference.

Figure 1 - description below

Figure 1

The example in Figure 1 shows an AAC device connected directly to the computer using a serial cable. The serial cable from the AAC device connects directly to the computer serial or "com" port, which is usually located at the rear of the computer. The user in Figure 1 wishes to make selections on their AAC device, transmit the information across the serial cable to the computer, and expects the computer to understand that the information represents keyboard or mouse actions. In Figure 1, the "connection" protocol as defined in the GIDEI Proposal includes the serial cable, its internal wiring or "pin-out" arrangement, and the amount, speed, and characteristics of the information the user sends from their AAC device to the computer. The "data communication" protocol as defined in the GIDEI Proposal concerns the contents of the information or "data packets" themselves, that the user either creates or which may be pre-stored on their AAC device.

You might expect that once the user sets up their AAC device to conform to both the connection and data communication protocol as defined in the GIDEI Proposal, that their AAC device would be able to communicate with and control the computer. Unfortunately, without one additional missing piece, the computer will not be able to understand what the AAC device is transmitting.

Computers are very powerful tools. However from a user input standpoint, most computers only understand the user when given input or instructions from the keyboard or the mouse. By design, keyboards and mice each use their own language to communicate with the computer. Therefore, once the AAC device is connected to the computer as shown in Figure 1 (e.g., either directly through the use of a serial cable or indirectly via some kind of wireless link), something must act as a "go-between" to translate the AAC device language into the keyboard or mouse language understood by the computer. Since the information transmitted from the AAC device is well defined by the GIDEI Proposal data communication protocol, a good portion of the translation work is already completed. In Figure 1, the missing "go-between" piece is the software that functions as the "emulating interface" on the computer receiving the alternate input device information. Emulating interface software would do the translation of the information sent from the AAC device into keyboard and mouse language understood by the computer. The emulation interface software is the missing "go- between" piece that allows the AAC device which is connected directly to the computer com port to "emulate" these standard input devices. The "SerialKeys" feature provided as part of the AccessDOS software package is an example of "emulating interface" software.

Figure 2 - description below

Figure 2

The AAC to computer connections shown in Figure 2 are very similar to the example shown in Figure 1, except the serial cable coming from the AAC device is now connected to a "black box" outside the computer rather than directly to the computer. (Again, please note that the serial cable could also be a wireless serial link). The black box has cables coming "from" the keyboard and mouse, and cables "exiting" the black box which connect to the computer at the same place the keyboard and mouse cables would have been plugged into the computer, had the black box not been used. The black box also has a connection for the serial cable used to connect to the AAC device. Again the "connection" protocol as defined in the GIDEI Proposal includes the serial cable, its internal wiring or "pin- out" arrangement, and the amount, speed, and characteristics of the information the user sends from their AAC device to the black box. The "data communication" protocol as defined in the GIDEI Proposal concerns the contents of the information or "data packets" themselves, that the user either creates or which may be prestored on their AAC device.

In this example, information is sent from the AAC device to the black box. Therefore, the black box needs to perform the necessary translation of the AAC device information prior to sending it to the computer through the keyboard and mouse cables. The black box becomes the missing "go-between" piece in this example. Since the black box is connected between the standard input devices and the computer, it understands the language used by the keyboard and mouse when talking with the computer, and is therefore capable of allowing the AAC device to again "emulate" the standard input devices. In this case, we would refer to the black box as an "emulating interface device," since it is actually a piece of hardware which a user could take from computer-to-computer, as their needs might dictate. The Trace Transparent Access Module (T-TAM) is one example of an "emulating interface device."

Figure 3 - description below

Figure 3

Figure 3 shows one more example connection. However, the example in Figure 3 shows how a non-GIDEI alternate input device might connect to a computer. The AAC device in Figure 3 is connected directly to the computer using a keyboard cable. Since there is no serial cable or wireless serial link involved, this example does not use the GIDEI Proposal.

The AAC device in Figure 3 does not use any kind of GIDEI connection, because this AAC device already has a keyboard emulation interface built into it which understands the keyboard language of the computer it is connected to. In this example, we would say that the AAC device is acting as both the "alternative input device" and the "emulating interface device." Some individuals may also call an AAC device with "direct keyboard connection" capability a "keyboard emulating interface," since the AAC device connects directly to a keyboard cable and "emulates" or looks like another keyboard to the computer. This terminology can be confusing however, since it does not distinguish between a device which is capable of connecting directly to the keyboard port or a device which emulates the keyboard using an external emulator. Perhaps a preferred term for this type of device would be to describe it as an alternative input device with built-in keyboard emulation. However, as stated above, this combination is still another example of keyboard emulation.

As technology advances, we expect more and more AAC devices to be designed capable of connecting directly to the computer as substitute or additional keyboards, mice, etc. These devices would not need to use the GIDEI connection and data communication protocol. However, until all alternative input devices are so equipped, the GIDEI Proposal provides a consistent method for users to connect with and operate a computer.

Standardization

The reasons behind the effort to standardize the GIDEI is based on several important and practical concerns:

In short, a standard as proposed by the GIDEI connection and data communication protocol simplifies development, makes it easier for people to connect their augmentative or alternate communication devices as alternate computer input devices, and provides access to more computers for those people that are unable to use the normal keyboard and mouse effectively.

GIDEI Overview

The GIDEI Proposal defines the connection and data communication protocol between alternate input devices and an emulating interface. The alternate input device, using this protocol, transmits information to the computer. The emulating interface then processes that information to determine which keystrokes to type or what mouse actions to perform on the computer. If it is a hardware emulating interface device, it may need to mimic the electrical signals that the normal keyboard and mouse exhibit. If it is a software emulating interface, it will place the keystroke and mouse information into locations within the computer or its operating system, where application programs will think it came from a user typing on the keyboard or from a user operating the mouse.

Some confusion arises when software or hardware developers state that they have a "general input device emulating interface," either in software or hardware. What they are referring to usually, is the fact that their interface can handle "general" input, thus it isn't limited to translating alternative input device information into only keyboard or only mouse languages. While reading this document, the General Input Device Emulating Interface (GIDEI) refers only to the connection and data communication protocol, not to any software or hardware designed to do translation.

The GIDEI connection protocol is designed to allow both wired and wireless links for GIDEI communication. Specifications have been made to allow for some degree of flexibility while taking into account the limitations of most current alternate input devices. Basic operation of the GIDEI is possible with virtually any alternate input device with a serial port and advanced options are included for alternate input devices that have additional capabilities.

The GIDEI Proposal defines two modes of operation as part of the data communication protocol for sending keystroke and mouse information: Character Mode and Escape Sequence Mode. In Character Mode, the emulating interface would understand to convert ASCII characters received from the alternate input device directly into whatever keystrokes are necessary to produce those same characters on the computer. The Escape Sequence Mode is designed to provide a way for a person using an alternate input device to type keys that have no ASCII equivalent (e.g., Home, PageUp, etc) as well as to allow the user to "hold" two or more keys down at the same time, as is required by many computers (e.g., Ctrl-Alt-Del). Escape Sequence Mode also allows the user to specify mouse actions such as clicking, double clicking and moving. Finally, Escape Sequence Mode is used to change certain operational features the GIDEI Proposal supports.

The GIDEI Proposal was developed with thought given to both hardware and software emulation interface implementations. Features such as key repeat and adjustable typing rate were deliberately removed from this proposal to take into account the fact that some emulating interface implementations could not guarantee access to a timing mechanism. Memory requirements were also considered when Commands and Key Names were established as part of the GIDEI data communication protocol. While the length of some of the Key Names could be shortened, this would have made it much more difficult for users to understand. Since many of the alternate input devices today require the user to program these escape sequence strings in "squares" or "selections" on their alternate input device, user readability was given greater priority than device memory requirements.

Previous versions of the GIDEI were concerned with maintaining a degree of compatibility with previous versions of the Keyboard Emulating Interface (KEI v1.0) standards. However, to provide better support for the newer and more powerful communication aids, GIDEI2 no longer guarantees such "backward" compatibility.

GIDEI Commands At A Glance

Keyboard Commands

Mouse Commands

Miscellaneous Command(s)

Definition of Terms

Alternate input device: Any device that can electronically output ASCII characters and is used as an alternative to the regular keyboard or other input device on a general purpose computer system. An alternate input device is used because a person finds it more accessible and effective than the regular keyboard (or other input device).

ASCII: ASCII is an acronym which stands for the American Standard Code for Information Interchange. What this means to the computer user is that usually numeric values represent characters inside the computer. For example, the ASCII code for the uppercase "A" is "65." Table 1 provides a listing of ASCII characters and their corresponding numeric or decimal code.

Emulating Interface: A "system" that accepts information from an alternate input device and transforms it into keystrokes or other input information in the computer.

Escape Character: The single character used to indicate the beginning of a GIDEI Escape Sequence. It is ASCII 27. In this document the escape character is designated by "<esc>."

Escape Sequence: A character string that starts with an escape character (ASCII 27) and ends with a period character (ASCII 46). Escape Sequences are used to send special commands and keystrokes.

Hardware emulating interface: Usually an "external" device that attaches to the computer and provides connection "ports" for AAC devices while simultaneously interacting with the computer in such a way that the computer is unaware that any external device is attached.

Key Name: The ASCII string of characters assigned by the GIDEI Proposal to designate each key on the normal keyboard.

Neutral Keyboard: The state of the keyboard when all "toggling" keys are in their "untoggled" position.

Secondary Key Function: One or more actions produced by a key when it is typed in combination with other keys. Secondary Key Functions are normally activated by holding down, for example, a [Shift] key, an [Alt] key, an [Option] key, a [Ctrl] key, etc., along with the key.

Software emulating interface: Software which is implemented as a co-process within the target computer. Typically, it is a program resident in the computer which uses the computer's serial port to communicate with the alternate input device. It is activated when the serial port receives characters. Once activated, it interprets the keystroke and mouse information and makes these keystrokes available to the operating system in that computer.

Special Keys: Keys that do not produce ASCII characters. An example is the "right arrow" key.

Transparent Interface: An interface that is invisible to or undetectable by the computer system and the software running on it. A emulating interface whose implementation is not distinguishable from the way the normal keyboard works. In other words, it is a interface that operates with a computer and the software running on it exactly the same way as the normal keyboard would operate. Ideally, all interfaces should be transparent to insure access to the same programs that can be operated from the normal keyboard or mouse.

XOFF Character: The character sent by the GIDEI to the alternate input device to tell it to stop transmission. The XOFF character is ASCII 19 (control-S).

XON Character: The character sent by the GIDEI to the alternate input device to tell it to resume transmission. The XON character is a ASCII 17 (control-Q).

Hardware Connection

This section defines specifications for the hardware connection or hardware interface portion of a the system.

The hardware interface is the component of the system which the user's AAC device "directly connects to." It handles the physical connection, signal interfacing, communications protocol and data buffering.

The GIDEI Proposal data connection protocol uses the RS-232C communication link for transferring information from an external AAC device to the hardware interface. The hardware interface itself might be under the control of emulating interface "software" running on a computer or a separate external "black box" connected to the computer.

See also Appendix A, regarding "Plug-and-Play."

Serial Connection

The serial connection is based on EIA Standard RS-232-C: Interface Between Data Terminal Equipment and Data Communication Equipment Employing Serial Binary Data Interchange, August 1969, Electronic Industries Association, Washington, D. C. 20006.

Of the 25 lines defined, four are used for the GIDEI Proposal.

Connector

Pin Assignments (for the AAC, or DTE, device)

(assuming the AAC device has a 25 pin D connector)

(Assuming the AAC device has a 9 pin D connector)

Transmission Format

Transmission Rate

Handshaking

Status Inquiry

Handling Framing Errors

Initial Connection Protocol

Reset Signal to the User

Handshaking After Changing Baud Rate By Command

Character Mode

Character Mode is the most common mode in which an alternative input device using GIDEI data communication protocol will be running. In this mode, ASCII characters sent from the alternate input device to the computer will be converted to the keystrokes necessary to produce that ASCII character on the computer.

Table 1 shows all the ASCII characters from 0 through 127. Characters which exist above 127 (e.g., ASCII 128 through ASCII 255), sometimes referred to as "Extended ASCII," may differ due to the computer or receiving device's operating system.

If your alternate input device is capable of sending the ASCII value for the character you need, most hardware interfaces will understand how to generate the character or key for your request. If some of the keys on a particular keyboard have single character labels which are ASCII characters in the Extended ASCII 128 to ASCII 255 range, GIDEI2 supports transmission of these characters and hopefully the hardware interface will understand how to "create" the character or keyboard "keys" via emulation on the receiving computer. For example, if you require an "e" with a circumflex accent "^" on a computer in the United States, GIDEI2 supports transmission of the Extended ASCII character "234"(ISO 8859-1 Standard) direct from the alternate input device to the hardware interface. (Note: remember the hardware interface may be either an external "black box" device connected to the receiving computer or emulation interface software running directly on the receiving computer.)

Two ASCII characters are reserved by the GIDEI for special use. They are the NULL character (ASCII 0), and the ESCAPE character (ASCII 27). See the Escape Sequence Mode section to find how to type these characters.

Based on the GIDEI Proposal, an emulating interface will leave Character Mode and enter Escape Sequence Mode upon receiving an Escape character. (see the next section for information on Escape Sequence Mode) Based on the GIDEI Proposal, after start up, after an escape sequence, and after an error in an escape sequence, the emulating interface will return to Character mode.

Example: if an ASCII d is sent, the interface will type a d on the computer. If an ASCII G is sent, the interface will type a shift key and a g to produce a capital G on the computer.

The actual keystrokes that the interface will type to get the character is dependent on the keyboard that the interface is emulating. The intention of the GIDEI is to allow the external AAC device to send characters that the hardware interface then translates into the appropriate key presses or mouse actions.

Table 1: ASCII Characters With Their Corresponding Decimal Code

Character Code Character Code Character Code
NULL 0 + 43 W 87
SOH (ctrl-A) 1 , 44 X 88
STX (ctrl-B) 2 - 45 Y 89
ETX (ctrl-C) 3 . 46 Z 90
EOT (ctrl-D) 4 / 47 [ 91
ENQ (ctrl-E) 5 0 48 \ 92
ACK (ctrl-F) 6 1 49 ] 93
BEL (ctrl-G) 7 2 50 ^ 94
BS (ctrl-H) 8 3 51 _ 95
HT (ctrl-I) 9 4 52 ` 96
LF (ctrl-J) 10 5 53 a 97
VT (ctrl-K) 11 6 54 b 98
FF (ctrl-L) 12 7 55 c 99
CR (ctrl-M) 13 8 56 d 100
SO (ctrl-N) 14 9 57 e 101
SI (ctrl-O) 15 : 58 f 102
DLE (ctrl-P) 16 ; 59 g 103
DC1 (ctrl-Q) 17 < 60 h 104
DC2 (ctrl-R) 18 = 61 i 105
DC3 (ctrl-S) 19 > 62 j 106
DC4 (ctrl-T) 20 ? 63 k 107
NAK (ctrl-U) 21 @ 64 l 108
SYN (ctrl-V) 22 A 65 m 109
ETB (ctrl-W) 23 B 66 n 110
CAN (ctrl-X) 24 C 67 o 111
EM (ctrl-Y) 25 D 68 p 112
SUB (ctrl-Z) 26 E 69 q 113
ESC 27 F 70 r 114
FS (ctrl-\) 28 G 71 s 115
GS (ctrl-]) 29 H 72 t 116
RS (ctrl-^) 30 I 73 u 117
US (ctrl-_) 31 J 74 v 118
SPACE 32 K 75 w 119
! 33 L 76 x 120
" 34 M 77 y 121
# 35 N 78 z 122
$ 36 O 79 { 123
% 37 P 80 | 124
& 38 Q 81 } 125
' 39 R 82 ~ 126
( 40 S 83 DEL 127
) 41 T 84
* 42 U 85
V 86
List 1: ASCII Characters With Their Corresponding Decimal Code

Character, Code

NULL 0
SOH (ctrl-A) 1
STX (ctrl-B) 2
ETX (ctrl-C) 3
EOT (ctrl-D) 4
ENQ (ctrl-E) 5
ACK (ctrl-F) 6
BEL (ctrl-G) 7
BS (ctrl-H) 8
HT (ctrl-I) 9
LF (ctrl-J) 10
VT (ctrl-K) 11
FF (ctrl-L) 12
CR (ctrl-M) 13
SO (ctrl-N) 14
SI (ctrl-O) 15
DLE (ctrl-P) 16
DC1 (ctrl-Q) 17
DC2 (ctrl-R) 18
DC3 (ctrl-S) 19
DC4 (ctrl-T) 20
NAK (ctrl-U) 21
SYN (ctrl-V) 22
ETB (ctrl-W) 23
CAN (ctrl-X) 24
EM (ctrl-Y) 25
SUB (ctrl-Z) 26
ESC 27
FS (ctrl-\) 28
GS (ctrl-]) 29
RS (ctrl-^) 30
US (ctrl-_) 31
SPACE 32
! 33
" 34
# 35
$ 36
% 37
& 38
' 39
( 40
) 41
* 42
+ 43
, 44
- 45
. 46
/ 47
0 48
1 49
2 50
3 51
4 52
5 53
6 54
7 55
8 56
9 57
: 58
; 59
< 60
= 61
> 62
? 63
@ 64
A 65
B 66
C 67
D 68
E 69
F 70
G 71
H 72
I 73
J 74
K 75
L 76
M 77
N 78
O 79
P 80
Q 81
R 82
S 83
T 84
U 85
V 86
W 87
X 88
Y 89
Z 90
[ 91
\ 92
] 93
^ 94
_ 95
` 96
a 97
b 98
c 99
d 100
e 101
f 102
g 103
h 104
i 105
j 106
k 107
l 108
m 109
n 110
o 111
p 112
q 113
r 114
s 115
t 116
u 117
v 118
w 119
x 120
y 121
z 122
{ 123
| 124
} 125
~ 126
DEL 127

Escape Sequence Mode

Many keys on the keyboard you wish to emulate or "type" do not have a "single" character label for a name. Some examples of this might be the "enter," "page up," "backspace," and "shift" keys. You cannot type or emulate these keys in Character Mode, since there is no single ASCII character you can type or transmit from the AAC device to represent them. To type these keys, you must use "Escape Sequence Mode." Escape Sequence Mode simply means to start a transmission of multiple characters with the "escape" character (e.g., ASCII or decimal 27) and end the transmission with a period character (e.g., ASCII or decimal 46). Therefore an escape sequence consists of an ESC character (ASCII 27), followed by a sequence of other ASCII characters (e.g., a Key Name, or GIDEI command), and ending with the PERIOD character (ASCII 46).

For purposes of this document, an "escape" character (ASCII or decimal 27) will be represented by "<esc>." Therefore an escape sequence would look like:

Key Names are nothing more than a string of ASCII Characters assigned to keys which do not have a "single" ASCII character to represent them. A base set of Key Names which GIDEI2 understands are listed in the Key Name Aliases at the end of this document. (Note, some hardware interfaces may support additional Key Names, which are not part of the GIDEI2 Proposal, but may be incorporated in future standards.)

To make Key Names easier to remember, many Key Names consist of the same characters as the label used for that key on the keyboard. For example, the Key Name for the "backspace" key is either "backspace" or "bspace." The shorter Key Name allows the user to conserve memory when programming that key selection on their alternate input devices, especially if they have a device with several possible selections. Many of the longer Key Names also have shorter equivalents for this purpose. However, longer Key Names are usually available for users who find it easier to learn and remember Key Names in this fashion.

The Escape Sequence Mode has several purposes besides just sending Key Names. Listed below are brief descriptions and examples of Escape Sequence Mode uses. For more explanation on Escape Sequence Mode commands, refer to the next sections.

Characters Allowed in GIDEI Escape Sequences

Capitalization

All characters in escape sequences are converted to lower case by most hardware or software interfaces prior to processing.

Spaces

Space characters (decimal 32) anywhere in the escape sequences are ignored by most hardware or software interfaces.

Format

Escape sequences use one of two possible syntaxes, which may not be evident to most users but is described here for GIDEI Proposal completeness. Escape sequences can either include the appropriate GIDEI Command name in the escape sequence or they can "imply" a particular command is being used. The following two examples are both escape sequences involved with the keyboard, however only one requires the use of a GIDEI command name

Error Handling

Resetting the Escape Sequence Mode

If the hardware interface is in Escape Sequence Mode and receives another escape character before getting the period character (e.g., ASCII or decimal "46") which terminates an escape sequence, then all the characters before this escape character are discarded. After discarding previous characters, the hardware interface remains in Escape Sequence Mode ready to start assembling a new escape sequence.

Command and Parameter Designations

Delimiting Characters within Escape Sequences

Miscellaneous Escape Sequence Commands

baudrate

Keyboard Escape Sequence Commands

combine

hold

lock

rel

Implied Press

Mouse Escape Sequence Commands

moureset

anchor

mougo

moustop

moulock

mourel

click

dblclick

goto

move

GIDEI Key Name Aliases

List of Currently Defined Key Names

A

aacute
acircumflex
acute
adieresis
ae
again
agrave
alphanumeric
alt
altgr
amp
ampersand
aogonek
apostrophe
apple
appskey
aring
ast
asterisk
at

B

backslash
backspace
bbar
break
bslash
bspace

C

cacute
cancel
capslk
capslock
ccaron
ccedilla
cedilla
circumflex
clear
cmd
colon
comma
command
compose
control
conversion
copy
ctrl
cut

D

dblquote
del
delete
dieresis
divide
dn
dollar
down

E

eacute
ecaron
ecircumflex
edieresis
egrave
eight
end
enter
equal
esc
escape
eth
exclaim
exclaimdown
execute

F

f1
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f2
f20
f21
f22
f23
f24
f3
f4
f5
f6
f7
f8
f9
find
five
four
front
fullsize

G

graphical
grave

H

help
hiragana
home
hyphen

I

iacute
icaron
icircumflex
idieresis
igrave
ins
insert

K

kana
kanji
kanjidict
kp*
kp+
kp-
kp/
kp0
kp1
kp2
kp3
kp4
kp5
kp6
kp7
kp8
kp9
kp=
kpcomma
kpdel
kpdivide
kpdn
kpdown
kpdp
kpend
kpenter
kpequal
kphome
kphyphen
kpins
kpinsert
kpleft
kpmidl
kpminus
kpperiod
kppgdn
kppgup
kpplus
kpright
kpslash
kpstar
kptimes
kpup

L

lalt
lbrace
lbracket
lcmd
lcommand
lcompose
lcontrol
lctrl
left
leftwinkey
linefeed
llthan
lock
lopenapple
loption
lparen
lquote
lshift
lthan
lwithslash

M

menu
meta
micro
minus
mordinal
multiply

N

ncaron
next
nine
noconversion
ntilde
number
numlk
numlock

O

oacute
ocircumflex
odieresis
oe
ogonek
ograve
ohungarumlaut
one
onehalf
onequarter
ooblique
open
openapple
option
otilde

P

pagedown
pageup
paste
pause
period
pf1
pf2
pf3
pf4
pgdn
pgup
plus
pound
prev
print
printscreen
props
prtscr

Q

question
questiondown

R

ralt
rbrace
rbracket
rcaron
rcmd
rcommand
rcompose
rcontrol
rctrl
remove
reset
ret
return
right
rightwinkey
ring
rolldown
rollup
romanize
ropenapple
roption
rparen
rshift

S

sacute
scaron
scroll
scrolllock
section
select
semicolon
seven
sharps
shift
shiftleft
shiftright
six
slash
small
space
stop
superone
superthree
supertwo
sysreq

T

tab
tcaron
three
tilde
triangle
two

U

uacute
ucircumflex
udieresis
ugrave
uhungarumlaut
underscore
undo
up
uring

V

vbar

W

wordreg
wordrem

Y

yacute
ydieresis
yen

Z

zcaron
zdotaccent
zero

Appendix A

The Plug and Play Architecture

The Plug and Play initiative is an industry-wide effort that promises to make PC installation and use easier for computer users.

Plug and Play is both a design philosophy and a set of PC architecture specifications. The ultimate goal of Plug and Play is to design intelligence into the PC itself, to handle installation and configuration tasks without user intervention. A Plug and Play system has a number of characteristics. First, any installation is a simple, fail-safe operation. For devices the installation is automatic: plug the device in, turn on the system, and it works. With a Plug and Play system, the user can insert and remove devices, or connect-to or disconnect-from a docking station or network, without restarting the system or fiddling with configuration parameters. The system determines the optimal configuration, and applications automatically adjust to take full advantage of the new configuration. Users do not need to modify expansion card jumper settings, or even modify operating system configuration files. The benefits to both users and computer industry members will be substantial, as PC ease-of-use will be enhanced while support costs will be substantially lowered.

Plug and Play COM

The Plug and Play COM specification, a component of the overall Plug and Play Architecture, presents a mechanism to provide automatic configuration capability to peripheral devices that connect to a PC using Asynchronous Serial Data Interchange on standard serial ports, commonly known as COM ports. This enables full Plug and Play for the PC system, including external serial peripherals, referred to here as COM Devices.

The essential elements of Plug and Play COM are:

Device Implementation

The full Plug and Play COM specification defines mechanisms that each Plug and Play COM device must implement to support identification, which in turn supports automatic configuration of the entire PC system without end-user intervention.

The solution of the COM device identification problem addresses major concerns of end-users, system integrators, and operating system vendors. It also presents an excellent business opportunity for providing measurable value and differentiation in the short term, by reducing the user difficulties and associated technical support costs.

There are two ways that serial device manufacturers can implement this specification. For simple hardware based devices (e.g., serial mice) the hardware (e.g., ASICs) will need revision. For intelligent serial devices (e.g., modems and printers) these changes can be implemented by controller code firmware changes. However, care has to be taken in the controller code to avoid false-positive (erroneous) detection of the COM Enumerator (confusing the application software with unexpected PnP ID) or failure to detect the COM Enumerator.

References

There is now a forum on the Compuserve Information Service to address Plug and Play in Personal Computers. Please refer to this forum for all your Plug and Play support needs. This forum is the official mechanism for support, information and discussion, as well as receiving current versions of Specifications. Type "GO PLUGPLAY" to access this forum. To obtain a Compuserve account (if you don't already have one) please call 1- 800-848-8199.

For further details on the Plug and Play architecture and implementation details, see the following documents, some may be available on the CompuServe Plug and Play forum:


Version Changes

Version 2.1


trace.wisc.edu
This document is hosted on the Trace R&D Center Web site. Please visit our home page for the latest information about Designing a More Usable World - for All.