![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to emulator CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDTahoe / new / X / libibm / doc|
Return to emulator CVS log | Up to [CSRG BSD Unix] / 43BSDTahoe / new / X / libibm / doc |
1.1 root 1: .RP
2: .TL
3: EMULATORS IN WORKSTATION UNIX
4: .AU
5: By David O. Bundy
6: Research System Programmer for ACIS/IBM
7: .AL
8: .AI
9: Institute for Research in Information and Scholarship
10: Brown University
11: Providence, Rhode Island 02912
12: .AB
13: This paper explains the need for and design of Emulators in
14: Workstation UNIX.
15: The development of this emulator package under UNIX was driven by the
16: fact that the existing line discipline and console driver interface do not
17: support the complexities of today's new workstations.
18: The complexities are that today's workstations do not consist of dumb
19: hardcopy terminals or character oriented consoles but
20: elaborate bitmapped displays with an assortment
21: of sizes, densities, capabilities, and protocols.
22: Workstations also include sophisticated keyboards
23: and mice that are separate from the terminal hardware
24: and need a different device driver.
25: To further complicate things, we can hang a mouse off any serial
26: port supported by the workstation and expect these mice to interact with the
27: console. Lastly, you can have more than one console or mouse on the
28: workstation simultaneously.
29: The challenge is to develop a package to which it is easy to add existing and
30: new devices. This package should be flexible enough to handle any
31: combination and number of devices at the same time.
32: .AE
33: .NH
34: History
35: .PP
36: In traditional UNIX the console driver takes character input
37: from a hardcopy terminal, send it to the selected line discipline to do
38: any filtering, and then echo the character back to
39: the console by passing it back to the hardware with
40: appropriate parity.
41: The line discipline filter performs any special functions depending on
42: the data passed (e.g. on receiving a delete character
43: the line discipline sends a signal to the process
44: running on the console).
45: .PP
46: Eventually non-hardcopy consoles with more intelligence appeared,
47: which could
48: decipher special character sequences for displaying
49: characters with different
50: attributes or at any location on the screen.
51: UNIX was expanded to handle this with the development of the
52: termcap package which
53: describes any particular console within a certain set of
54: capabilities and how operations are performed
55: on that console. All this information is represented in fixed rules in a
56: termcap data base for easy access.
57: .PP
58: By giving the user a software package which reads in any particular
59: terminal's information from the the termcap data base and performs any
60: requested function based on that terminal's capabilities, the user is now
61: relieved from knowing what hardware he/she is coding to.
62: The application only needs to know what functions are available
63: in the termcap toolbox in order to work on any terminal.
64: .PP
65: The cominbation of the termcap data base and line discipline filtering was
66: sufficient but does not support today's new complications of bitmap displays and
67: sophisticated keyboards/mice.
68: .NH
69: Todays Workstations
70: .PP
71: The first problem is that bitmap displays are not character oriented so you
72: can not send a character to the display and have it appear on the
73: screen. Second, bitmap displays do not have capabilities that fit into
74: the normal termcap data base (e.g. there is no character sequence to tell the
75: display where to put a character). Lastly the new keyboards and mice are
76: separated from the display and do not return ascii characters, but codes
77: which must be translated to determine what action has taken place
78: (up and down key transitions, etc.).
79: .PP
80: In order to integrate this
81: into the existing system, it was determined that an extension was needed
82: to the normal console/line discipline structure.
83: .PP
84: Before listing the requirements of the emulator package,
85: I will explain and compare what
86: a line discipline and an emulator are and what each is used for.
87: This will help in understanding why the
88: .ul
89: emulator package
90: was needed.
91: .NH
92: What is a Line Discipline?
93: .PP
94: A
95: .ul
96: line discipline
97: acts like a filter between the user
98: and communication hardware on the workstation.
99: A line discipline is a form of higher level software controller for
100: communication lines. Essentially, a line discipline will buffer the user
101: from handling the data stream responsibilities from/to communication lines.
102: The following list summarizes the functions that the standard
103: terminal-oriented line disciplines handle:
104: .RS
105: .IP 1.
106: Input lines are collected and input editing is provided.
107: The edited line is made available when it is completed by a newline or
108: when an EOT (end of transmission)
109: is detected. A line will be buffered up to 256 characters.
110: .IP 2.
111: Any input characters can be mapped to special functions for line editing or
112: interrupt generation.
113: .IP 3.
114: Input characters are buffered if the process can not read the data
115: faster than it is received.
116: .IP 4.
117: Output processing like delay generation, tab expansion,
118: erasing characters from the screen on input editing, echoing of control
119: characters and other unprintable characters in special formats, and other
120: functions such as mapping lower case characters to upper case for terminals
121: that only handle upper case.
122: .IP 5.
123: Flow control for output processing. This consist of controlling the flow
124: between the process sending characters and the display. The line
125: discipline will buffer data from the process to the terminal/display and
126: suspend the process if data is arriving faster then the display can show
127: it.
128: .IP 6.
129: A user can control the output flow by typing special control
130: characters to flush the output, and stop/start the output.
131: .IP 7.
132: Other line disciplines allow some or all input/output processing to be
133: excluded so that character by character input or raw data can be accepted.
134: .IP 8.
135: Other line disciplines know about certain protocols that may come in
136: on networked communication lines.
137: .RE
138: .PP
139: Line discipline filtering is very powerful
140: and important but does not completely satisfy the requirements of
141: today's input/output devices. The major
142: deficiency is that we need to deal with more than character data
143: manipulation.
144: .NH
145: What is an Emulator?
146: .PP
147: Bitmap terminals are bit addressable and
148: do not deal with characters but with turning on/off and moving
149: bits on the screen. To represent a single character on the screen a bitmap
150: terminal must have a number of bits at different locations turned on/off.
151: To scroll a bitmap screen you must move all the bits on the screen up a
152: line and turn off the bits on the bottom line with all this depending on
153: the size of the font used etc.. Some bitmap terminals will do some or all
154: of this in hardware for you.
155: It is then clear that each bitmap terminal must have
156: code written to control them for doing standard operations in
157: order to act like a normal
158: .ul
159: glass tty style console.
160: So the question is: What
161: software do you need to make a bitmap display take characters and command
162: strings like a glass tty? Once this software is written it can be
163: intergrated with the existing line disciplines which handles character
164: manipulation for us.
165: .PP
166: Since we want to support multiple types of displays, the question also
167: comes up: What is the best way to design the code so that we can emulate a
168: glass tty on each display without reproducing the same code for each
169: display? The emulator package gives you a solution. It is a
170: intermediary between the low level device specific drivers and the higher
171: level line disciplines. On output it differentiates
172: the set of Generic functional procedures that must be
173: device-dependent for controlling each display
174: and device-independent code which deciphers character streams and
175: decides when to perform an action on the display.
176: The device dependent set of procedures have to be sufficient
177: enough so that a piece of code, emulator, can be written with them and be
178: able to support normal glass tty operations.
179: .PP
180: Therefore, an emulator is the code that intercepts
181: characters and analyzes them according to the type of tty it emulates and
182: then calls the appropriate display/device dependent procedures to perform
183: the operation on the display. With this separation, any emulator written
184: will work on any display on the workstation without having to know anything
185: about the display. This type of emulator will be know as an
186: .ul
187: output emulator.
188: .PP
189: This notion can be expanded to input emulation as well. This would enable
190: any keyboard or mouse on the system to pass data through an input
191: emulator filter and have the resulting filtered data be presented to the
192: user in any particular format.
193: Therefore, an
194: .ul
195: input emulator
196: will be know as an emulator that accepts data from a keyboard and a mouse
197: and deciphers the data to present actual ascii characters (usually), and mouse
198: button/motion data reports.
199: .PP
200: Once an emulator is written it then can take output from or give input to
201: the normal line discipline routines as if the emulator was a normal UNIX
202: tty hardware driver. It should be noted here that the emulator
203: package also supports window manager type device-dependent
204: routines. This facilitates the implementation of
205: emulators which do not want to act like a
206: glass tty but rather be an interface to a window manager/graphics system
207: which takes control of output to the screen.
208: .NH
209: The Output Emulator Interface to the Low Level Display Dependent Routines
210: .PP
211: I have found that the following device dependent procedures are enough to
212: support any basic output emulator.
213: .RS
214: .IP 1.
215: Probe the display to see if it is there.
216: .IP 2.
217: Initialize the display.
218: .IP 3.
219: Position cursor anywhere on the display.
220: .IP 4.
221: Take a character and put up a bitmap, from some internal data font,
222: that represents that
223: character where your cursor is currently pointing.
224: .IP 5.
225: Blank a given section of the display (by character).
226: .IP 6.
227: Move a group of lines on the display.
228: .IP 7.
229: Print the screen contents on the standard printer.
230: .RE
231: .PP
232: Besides these base procedures, an emulator also needs general information
233: about the display it will be using like how many lines, and how wide a line
234: will fit on the screen with the font the display dependent routine is
235: using. The following is the structure that describes the interface between
236: the emulator and the display-dependent routines. The top part down to
237: .ul
238: flags
239: is the standard glass tty information; the other entries will be
240: described later when I explain how window manager systems integrate into the
241: emulator package. The following is from "screen_conf.h". This structure
242: is initialized in "screen_conf.c".
243: .sp 2
244: .nf
245: struct screen_sw {
246: char *name; /* Name of Display */
247: int (*probe)(); /* Probe for Screen */
248: int (*init)(); /* Initialize Screen */
249: int (*s_putc)(); /* Put character on Screen */
250: int (*pos_cur)(); /* Position Cursor on Screen */
251: int (*blank)(); /* Blank A section of Screen */
252: int (*move)(); /* Move Some lines on Screen */
253: int (*printscreen)(); /* routine to print screen */
254: char *rwaddr; /* Read & writable addr on screen */
255: short lines; /* Number of lines on screen */
256: short width; /* Width of screen in characters */
257: short vbits; /* Vertical number of screen bits */
258: short hbits; /* Horizontal number of screen bits */
259: int flags; /* some flags about the screen */
260: int def_oute; /* Default output emulator */
261: int (*pos_loc)(); /* Position Locator on Screen */
262: int (*load_loc)(); /* Load Locator description */
263: int (*show_loc)(); /* Show Locator on Screen*/
264: int (*hide_loc)(); /* Hide Locator on Screen */
265: int (*apa_init)(); /* All Points Addressable screen init */
266: int fill_int[14]; /* Fill out to 32 ints (2^7) */
267: };
268: .sp 2
269: .fi
270: .RE
271: .PP
272: The following is a synopsis from "screen_conf.h" which shows the interface to
273: the above structure. All that the emulator needs to use are the following
274: routines and attributes.
275: .sp 2
276: .nf
277: /* General Defines for emulators to use with the screen_sw structure */
278: #define WS si->which_screen
279: #define SCREEN_LENGTH (screen_sw[WS].lines)
280: #define SCREEN_WIDTH (screen_sw[WS].width)
281: #define SCREEN_SIZE (SCREEN_LENGTH * SCREEN_WIDTH)
282: #define STATUS_LINE (SCREEN_LENGTH - 1)
283:
284: /* Character Attributes */
285: #define NORMAL_VIDEO 0x01
286: #define REVERSE_VIDEO 0x02
287: #define UNDERLINE_VIDEO 0x04
288: #define HI_INTENSITY 0x08
289: #define BLINK 0x10
290:
291: /* Defines for calling console screen dependent switched routines */
292:
293: /* Put character 'c' with attribute 'screen_attr' on console */
294: #define screen_putc(c, screen_attr) (*screen_sw[WS].s_putc) (c, screen_attr)
295:
296: /* Move cursor to x,y position */
297: #define pos_cursor(x, y) (*screen_sw[WS].pos_cur) (x, y)
298:
299: /* blank with screen_attribute from start coordinates to end coordinates */
300: #define screen_blank(s_a, sy, sx, ey, ex) (*screen_sw[WS].blank) (s_a, sy, sx, ey, ex)
301:
302: /* Macro for blanking a line */
303: #define blank_line(s_a, line) screen_blank(s_a, line, 0, line, SCREEN_WIDTH-1)
304:
305: /* move line1 ... line2 to dest */
306: #define screen_move(l1, l2, dest) (*screen_sw[WS].move) (l1, l2, dest)
307:
308: /* Position screen locator on screen at x,y position with msbox restriction */
309: #define pos_locator(x, y, msbox) (*screen_sw[WS].pos_loc) (x, y, msbox)
310:
311: /* Load a new screen locator discription with msbox restriction */
312: #define load_locator(c, msbox) (*screen_sw[WS].load_loc) (c, msbox)
313:
314: /* Show screen locator with msbox restriction */
315: #define show_locator(msbox) (*screen_sw[WS].show_loc) (msbox)
316:
317: /* Hide screen locator */
318: #define hide_locator() (*screen_sw[WS].hide_loc) ()
319:
320: /* APA Screen init */
321: #define apa_initialize() (*screen_sw[WS].apa_init) ()
322: .sp 2
323: .fi
324: .RE
325: .NH
326: Input Emulator Interface to Input Device Dependent Routines
327: .PP
328: The input emulator low level interface is not as strictly defined as the
329: output emulator interface. Essentially there are a set of hardware routines
330: in
331: .ul
332: keyboard.c
333: and
334: .ul
335: mouse.c
336: which an input emulator can call to control the keyboard, speaker, and
337: mouse.
338: The interface to input emulators is much
339: less rigid than an output emulator (this should change in the future).
340: Basically the input emulator
341: will receive an interrupt with data from the keyboard or mouse along with
342: an indication of which sent the interrupt.
343: The emulator is then responsible for deciphering the data and keeping track
344: of the state of the device. The input emulator will then pass on its
345: processed data to the user through a
346: .ul
347: line discipline
348: or through some other emulator specific method (shared memory, etc.).
349: .PP
350: There are only a few procedures needed to control a keyboard for setting
351: things like the auto keyclick rate, bell tone, and key characteristics
352: (repeat rate, make/break, etc.). And because any workstation I have run
353: into so far only supports one keyboard at a time,
354: there is no reason to set up a
355: switch table for these hardware routines, yet!
356: Workstation mice also have few control operations (set sampling or
357: resolution rate) and input emulators, as yet, do not deal with these directly
358: but instead pass on
359: .ul
360: ioctl
361: system calls to the appropriate driver for these operations.
362: .NH
363: Window Manager Device Dependent Routines
364: .PP
365: The following lists the window manager type Device Dependent Routines which
366: are available with the
367: .ul
368: screen_sw
369: low level routines. These are normaly used in an input emulator in order to
370: control the mouse tracking to the display cursor/locator.
371: .RS
372: .IP pos_loc()
373: Position the locator at a given coordinate on the display.
374: .IP load_loc()
375: Load a locator bitmap for the display. This will be the locator until the
376: next load_loc.
377: .IP show_loc()
378: Make the locator visible and keep showing when positioned.
379: Usually used after a hide_loc.
380: .IP hide_loc()
381: Make the locator invisible but does not effect the tracking.
382: .IP apa_init()
383: All Points Addressable Init the display for graphic type operations needed
384: for using the locator on the display. Usefull for displays with hardware
385: cursors/locators.
386: .RE
387: .NH
388: System Interface to the Emulator
389: .PP
390: Given the above any emulator can be written, but more is needed than
391: supplying the routines and interface for an emulator to use.
392: You must be able to add a new emulator to the system easily and have
393: support for allowing that new emulator to coexist with other emulators.
394: An emulator is much like a tty hardware device driver with many similar
395: system entry points and functions. The main difference is that they
396: all funnel through one console driver and all call a
397: common set of hardware routines. They never deal with the hardware
398: directly as device drivers do.
399: To put an emulator into the system you must add the following routines and
400: place them into the following switch table structure
401: (modeled after line disciplines). This structure is declared in
402: .ul
403: screen_conf.h
404: and the table is initialized in
405: .ul
406: screen_conf.c.
407: .sp 2
408: .nf
409: /*
410: * Emulator line control switch.
411: */
412: struct emulsw
413: {
414: int (*e_open)();
415: int (*e_close)();
416: int (*e_read)();
417: int (*e_write)();
418: int (*e_ioctl)();
419: int (*e_rint)();
420: int (*e_putc)();
421: int (*e_select)();
422: int (*e_putstatus)(); /* to put up status information */
423: int fill[7];
424: };
425: .sp 2
426: .fi
427: .PP
428: This emulator switch table
429: list all routines necessary for a device driver to interface with an
430: emulator.
431: Therefore each emulator, depending on its needs, will have the following
432: entry points in the kernel.
433: .RS
434: .IP E_OPEN
435: .br
436: Open the emulator to do any initialization necessary. Perform initial
437: operations like clearing the screen, initialize the cursor, and position
438: the cursor on the screen.
439: .IP E_CLOSE
440: .br
441: Close the emulator; do any cleanup necessary.
442: .IP E_READ
443: .br
444: Read data from the emulator. This routine usually forwards the read
445: request to the user defined line discipline. The read routines in line
446: disciplines currently perform all the operations necessary for this routine.
447: This consist of taking the already received characters off a
448: .ul
449: clist queue
450: and passing them to the user program's read buffer.
451: .IP E_WRITE
452: .br
453: Write data to the emulator. This procedure takes a character stream
454: passed from the
455: user level program. The emulator usually calls the line discipline which
456: the user has specified to do any character preprocessing.
457: Again, the line discipline routines already perform the necessary duties
458: for this routine. This routine and the E_READ routines are in the emulator
459: package for completeness and allowing for future flexibility.
460: You will find that some specialized emulators do use these routines for other
461: than calling the associated line discipline routines (see buf_emul).
462: .IP E_IOCTL
463: .br
464: I/O control to emulator for changing or setting any characteristics of the
465: emulator or performing operations which do not fit into the normal
466: interface to the emulator. An emulator's IOCTL routine should return a (-1)
467: if the command is not recognized.
468: .IP E_RINT
469: .br
470: Receive interrupt to emulator. This procedure is only needed by input
471: emulators. The emulator receives an interrupt from
472: a driver's interrupt routine
473: and processes the data depending on the type of
474: interrupt received.
475: This procedure will then pass on the processed input data
476: to the user assigned line discipline input routine.
477: Some specialized window manager emulators will not forward this data to a
478: line discipline but do their own queuing and interaction with the window
479: manager.
480: .IP E_PUTC
481: .br
482: Put a character on the display. This emulator routine is passed a
483: character from a user's write or kernel print. The emulator is then
484: responsible to decipher the data passed and do any emulation before passing
485: the appropriate characters to the hardware putc routine.
486: This is the procedure which makes use of the screen switch table (screen_sw)
487: to call the device dependent routines to perform the emulation on any
488: display.
489: .IP E_SELECT
490: .br
491: Select call to emulator. This routine is used in input emulators to
492: perform the normal select duty of informing the user process
493: when new data is ready.
494: .IP E_PUTSTATUS
495: .br
496: Put status call to emulator. The emulator is responsible to take the
497: string passed and place it at an offset on the status line.
498: .RE
499: .NH
500: What the Emulator Package gives you
501: .RS
502: .IP 1.
503: Probe and initialize every display that is present on the workstation.
504: .IP 2.
505: Decide which display should be the default on bootup.
506: .IP 3.
507: A way for the user to reinitialize any hardware or emulator.
508: .IP 4.
509: A default emulator is defined for any particular hardware so that at
510: start up an application does not have to choose an emulator.
511: .IP 5.
512: A mechanism to select between the set of existing emulators for a display.
513: .IP 6.
514: Multiple displays running on the system simultaneously.
515: Each display can be associated with a different process. This allows
516: a separate login to run on each display.
517: .IP 7.
518: Emulators are written to support more than one display at a time,
519: multithreaded.
520: .IP 8.
521: A way to switch between the displays currently open on the workstation.
522: When you switch screens the focus of the keyboard and mouse follows to that
523: display. With this you can run a different window system on each display
524: and hot-key between them.
525: .IP 9.
526: A way to find out and change what the hot-key is.
527: .IP 10.
528: A way to lock out the user or system from using the display.
529: User lockout
530: is useful for window managers that wish to lock out other applications
531: from taking over the screen after they have.
532: Kernel or system lockout is useful when you don't want the kernel to
533: attempt to use a display for output because the controller has no display
534: hanging off it.
535: .RE
536: .NH
537: How does the console driver fit all this together?
538: .PP
539: The following diagram shows the relation of all the parts of the system I
540: have described with the standard
541: parts of a UNIX system.
542: .sp 1
543: .TS
544: center box;
545: cb s s
546: c s | cb
547: c | c | cb
548: .
549: Console System Diagram
550: =
551: User Application User Level
552: \_ \_ \^
553: System Call Interface Event Queue in \^
554: \^ Shared Memory \_
555: \^ \^ Kernel Level
556: \_ \_ \^
557: Line Discipline Package Emulator Package \^
558: \_ \_ \^
559: Standard Device Drivers Low Level Display \^
560: \^ Dependent Routines \^
561: \_ \_ \_
562: Displays/Keyboard/Speaker System or Serial Mouse Hardware
563: .TE
564: .PP
565: The above is a conceptual view of the system and does not show you all
566: the specific parts and what interfaces with what, but it does
567: give you an idea of the levels of flow.
568: The console driver is now a controller/router of sorts.
569: It takes the normal driver
570: requests and routes them to the correct display and display's
571: input/output emulator depending on the minor device specified.
572: The following shows how the minor device number maps to an emulator and display:
573: .sp 1
574: .TS
575: center allbox;
576: cb s
577: c c
578: .
579: Minor Device Number
580: _
581: Emulator FLAG Display number
582: High Nibble Low Nibble
583: 0 or 1 0 ... 15
584: .TE
585: .PP
586: The following is a list of currently used displays on our system.
587: .sp 1
588: .TS
589: center allbox;
590: cb s s
591: n l l
592: .
593: Console Displays
594: _
595: Display # Symbolic Name Description
596: 0 CONS_GEN Generic console (Current display)
597: 1 CONS_AED ACIS Experimental Display (Stream ordered)
598: 2 CONS_MONO Standard Monocrome (Character driven)
599: 3 CONS_APA8 All Points Addr with 8 bit bus (Bitmap)
600: 4 CONS_APA16 All Points Addr with 16 bit bus (Bitmap)
601: 5 CONS_APA8C All Points Addr color with 8 bit bus (Bitmap)
602: .TE
603: .PP
604: The emulator field in the minor device number is used to tell the console
605: driver to use the default glass tty input/output emulators for the display (0)
606: or to indicate that a nonstandard combination of input/output emulators will
607: be used by the user (1). This is needed so that the system will know to
608: restore the display to the
609: .ul
610: standard state (default emulators)
611: wen the program exits.
612: The following is a list off all current emulators available:
613: .sp 1
614: .TS
615: center allbox;
616: cb s s
617: n l l
618: .
619: Emulators available
620: _
621: Emulator # Symbolic Name Description
622: 0 E_STDINPUT Standard Input Emulator
623: 1 E_STDOUTPUT Standard Output Emulator
624: 2 E_IBMOUTPUT IBM 3101 Output Emulator
625: 3 E_ANSIOUTPUT ANSI Output Emulator (Not implemented)
626: 4 E_XINPUT X Event Queuing Input Emulator
627: 5 E_BUFOUTPUT Buffering Output Emulator
628: 6 E_MACINPUT Macintosh Event Queuing Input Emulator (Not Avail)
629: 7 E_MACOUTPUT Macintosh Output Emulator (Not Avail)
630: 8 E_KBDINPUT Intelligent Keyboard mapping Input Emulator
631: 9 E_AED Raw AED microcode interface Emulator
632: .TE
633: .sp 1
634: .PP
635: The
636: .ul
637: default emulators
638: for each display are:
639: .sp 1
640: .TS
641: center allbox;
642: cb s s
643: l | l l
644: .
645: Default Input/Output Emulators for each display
646: Display Input Emulator Output Emulator
647: AED E_STDINPUT E_STDOUTPUT
648: MONO E_STDINPUT E_IBMOUTPUT
649: APA8 E_STDINPUT E_IBMOUTPUT
650: APA16 E_STDINPUT E_IBMOUTPUT
651: APA8C E_STDINPUT E_IBMOUTPUT
652: .TE
653: .NH 2
654: Input From Keyboard Scenario
655: .RS
656: .IP 1.
657: User types character on keyboard.
658: .IP 2.
659: Receive Interrupt in keyboard driver, keyboar.c, interrupt routine
660: .ul
661: cnrint().
662: This routine extracts the key code from the hardware.
663: .IP 3.
664: Call emulator receive interrupt routine from the switch table indexed by
665: the current
666: .ul
667: input focus
668: after setting the
669: emulator structure flag indicating that this was a keyboard interrupt.
670: .IP 4.
671: Emulator will check if this was a keyboard interrupt.
672: If so it will either translate code into a character
673: and call normal line discipline routine for this console with the character
674: that it mapped the code to or
675: perform some emulator specific function like store the raw key
676: code in a shared memory area (X like)
677: and set a semaphore, also in shared memory, for
678: the user process to know that a new event has arrived.
679: .IP 5.
680: If a line discipline input routine is called, it will then perform any of
681: its normal input editing/mapping talked about previously and pass the
682: result to the user through the read system call interface.
683: .IP 6.
684: If a shared memory queue interface was used the user process would note
685: the queue update through the semaphore and then proceed to read the data
686: from the shared memory without preforming a read or any other system call.
687: .IP 7.
688: In either of the above two cases, if the user has previously done a select
689: call, he/she would then have the select satisfied.
690: .RE
691: .NH 2
692: Output To Display Scenario
693: .PP
694: This
695: .ul
696: scenario
697: only applys to glass tty operations and not window managers since window
698: manager system go directly to the display hardware through its own
699: graphics routines. A special
700: .ul
701: buffer emulator
702: has been set up to handle the case it someone trys to write through the
703: system to the display while a window manger is controlling the display.
704: This emulator would then be called, instead of a glass tty like emulator,
705: in the scenario listed below.
706: .RS
707: .IP 1.
708: The user performs a
709: .ul
710: write system call
711: with a buffer of data for the display. This data consists of straight
712: ascii data or display order streams.
713: .IP 2.
714: The console write routine will then call the minor device switched
715: output emulator's write routine.
716: .IP 3.
717: The output emulator write will usually then forward this data to the line
718: discipline write routine specified by the user. Certain emulators, like the
719: .ul
720: buf emulator
721: mentioned, will intercept this data and capture it for printing latter or
722: any other specific need.
723: .IP 4.
724: The line discipline will interpret the data and call the console start
725: routine, as normal, to print the ascii characters.
726: .IP 5.
727: The console driver's start routine loops through
728: dequeuing each character and calling
729: the output emulator put-character routine,
730: .ul
731: e_putc,
732: for each character.
733: .IP 6.
734: The output emulator
735: .ul
736: put-character routine
737: then deciphers the data and
738: calls the appropriate device-dependent routine to display the
739: character or perform the display command.
740: .RE
741: .NH
742: The User interface to the Emulators
743: .PP
744: As with standard UNIX the user interfaces to the system through system
745: calls to the console driver. The following explains how this interface has
746: changed to support the emulator package and multiple devices.
747: For more details on the
748: .ul
749: console and mouse drivers
750: you should see
751: .ul
752: cons(4) and ms(4).
753: .NH 2
754: Interface to Keyboard Input and Display Output
755: .NH 3
756: Standard Interface
757: .PP
758: In the simplest case a user program would still perform the same
759: operations as in the past, therefore allowing previously written programs to
760: work without change. The following lists the normal scenario and what the
761: emulator package does:
762: .RS
763: .IP 1.
764: An application, say login, opens "/dev/console".
765: Since "/dev/console" is the special CONS_GEN minor device, the open is
766: mapped to the current input focused display. The effect is that the
767: display at which you start a program is the display that is associated with
768: the process. The system will then start the default input and output
769: emulators for that display.
770: .IP 2.
771: The application reads or writes to the file descriptor returned
772: from the open system call.
773: The system will map reads or writes to the GEN_CONSOLE minor device
774: to the display with the current input focus which causes the appropriate
775: display indexed input/output emulators to be used.
776: .IP 3.
777: The application exits or closes "/dev/console" file descriptor. The system
778: will close the input/output emulators and the stream for the display with
779: the current input focus.
780: .RE
781: .PP
782: This mapping of "/dev/console" to the current display is important for
783: most applications which do not want to bother with which display they are
784: running on. This mapping is also very important
785: at system bootup time where the single user
786: shell does not know what display it
787: is starting on and it is simply mapped to the what the system choose as the
788: starting input focus.
789: But you want to tell some applications (e.g. login, widow manager.) which
790: .ul
791: display
792: they should start on.
793: Therefore, the following devices where made to support the displays
794: available on our system.
795: .TS
796: center allbox;
797: cb s s s s
798: c c c c c
799: l l c c l
800: .
801: Standard TTY Like Display Devices
802: _
803: Protections Owner Major Minor Device
804: crw-rw-rw- root 0, 0 /dev/console
805: crw-rw-rw- root 0, 1 /dev/ttyaed
806: crw-rw-rw- root 0, 2 /dev/ttymono
807: crw-rw-rw- root 0, 3 /dev/ttyapa8
808: crw-rw-rw- root 0, 4 /dev/ttyapa16
809: crw-rw-rw- root 0, 5 /dev/ttyapa8c
810: .TE
811: .PP
812: To start up an application on a particular display, all that is needed is
813: to reassign its standard input and outputs to any one of these devices or
814: have the application specifically open one of them. The system will then
815: handle the routing of output from that application to the appropriate
816: display and its default emulators. Input to the application from the
817: keyboard will only occur when the input focus is assigned to that display.
818: To switch between open displays you can hit the specified hot-key for your
819: system or use an application which performs an
820: .ul
821: ioctl system call
822: to set the input focus.
823: .PP
824: Putting this all together with the startup facilities in UNIX you
825: can now specify the different displays you have on your system in the
826: .ul
827: /etc/ttys
828: startup file and tell the system to start logins on each one of the
829: displays. A user can then hot-key to the display he/she wishes to use and
830: after logging in run any applications needed. Any application started on that
831: display will stay associated with it because it was started while the input
832: focus was on that display. Remember that this is an
833: application transparent mapping to that display taking place in the
834: kernel. Therefore a user can log on as many of the displays simultaneously
835: as needed.
836: .NH 3
837: Nonstandard Interface
838: .PP
839: For applications which call for a specific emulator that might not be the
840: default for a particular display, the following devices have been created.
841: .sp 1
842: .TS
843: center allbox;
844: cb s s s s
845: c c c c c
846: l l c c l
847: .
848: Nonstandard Display Devices
849: _
850: Protections Owner Major Minor Device
851: crw-rw-rw- root 0, 17 /dev/aed
852: crw-rw-rw- root 0, 18 /dev/mono
853: crw-rw-rw- root 0, 19 /dev/apa8
854: crw-rw-rw- root 0, 20 /dev/apa16
855: crw-rw-rw- root 0, 21 /dev/apa8c
856: .TE
857: .PP
858: You will notice that the emulator bit flag is on for each of these
859: devices. This indicates to the system that a nonstandard input and/or
860: output emulator is going to be used on this display and that on close the
861: system should return the display to its default emulators.
862: The system will open the standard input emulator and a special
863: buffering output emulator. This is done because most applications that
864: open the nonstandard device will take over the screen and want any output
865: from other sources (such as kernel prints) to be buffered and displayed
866: when the display is closed. See the manual page on the
867: .ul
868: buf emulator
869: for more information.
870: .PP
871: The following is a list of commands through the
872: .ul
873: ioctl system call
874: to the console emulator package:
875: .TS
876: center allbox;
877: cb s s s
878: c c c c
879: l l l ltw(3i)
880: .
881: Ioctl Commands to Emulator Package
882: _
883: Command Read Write Description
884: CON_SELECT_SCREEN Yes Yes T{
885: Input focus is set to display Number (Arg > 0) or to next display in list
886: (Arg < 0). Previous display number is returned.
887: T}
888: CON_GET_SCREEN Yes No T{
889: Just returns the current input focus display number.
890: T}
891: EIGETD Yes No T{
892: Get the number of the current input emulator for this display.
893: T}
894: EOGETD Yes No T{
895: Get the number of the current output emulator for this display.
896: T}
897: EISETD Yes Yes T{
898: Set the input emulator and return the previous for this display.
899: T}
900: EOSETD Yes Yes T{
901: Set the output emulator and return the previous for this display.
902: T}
903: CON_INIT_SCREEN No Yes T{
904: Initialize the specified display (Arg >= 0) or
905: this display (Arg < 0).
906: T}
907: CON_GET_FOCUS_CODE Yes No T{
908: Get the current keyboard code for setting the input focus (hot-key code).
909: T}
910: CON_SET_FOCUS_CODE Yes Yes T{
911: Set the current keyboard code for setting the input focus (hot-key code),
912: and return the previous code.
913: T}
914: SCRIOCGETF Yes Yes T{
915: Get screen control flags for the given display number.
916: T}
917: SCRIOCSETC Yes Yes T{
918: Set screen control flags for the given display number.
919: T}
920: .TE
921: .PP
922: All of the above commands take integer arguments except the last two
923: (SCRIOCGETF and SCRIOCSETC) which use the following structure:
924: .sp 2
925: .nf
926: struct screen_control {
927: int device; /* which screen/display to control */
928: int switches; /* Flags for this screen */
929: };
930: .fi
931: .sp 1
932: .TS
933: center allbox;
934: cb s
935: c c
936: l l
937: .
938: Flags/Switches for Each Display
939: Flag Description
940: CONSDEV_PRESENT Display is present on this system.
941: CONSDEV_KERNEL Display is available to the kernel.
942: CONSDEV_USER Display is available to the user.
943: CONSDEV_INIT Display has been initialized for output.
944: CONSDEV_OPEN Display has been open directly by minor device number.
945: .TE
946: .PP
947: All of the above
948: .ul
949: ioctl system calls
950: are
951: .ul
952: device independent controls
953: for dealing with the emulators. Each emulator has its own set of ioctls
954: for its own emulation purposes. These other
955: .ul
956: ioctls
957: are used in window manager type emulators for operations such as
958: passing/positioning the mouse locator for/on the display.
959: See the man page for any particular emulator for more information.
960: .NH 2
961: Mouse Input Interface and Other Input Devices
962: .PP
963: The interface to the system mouse is similar to that for the keyboard.
964: If you open the generic mouse device
965: .ul
966: /dev/ms,
967: minor device 0, the mouse input will be attached to the display which the
968: current input focus is on. Opening any other mouse device will attach the
969: mouse input stream to the process only when the input focus is on the
970: associated display. Since there can be a large assortment of serial type
971: hardware ports in which you can hang a mouse off of I have decided, for the
972: present, not to change all the associated drivers to support the console
973: like minor devices and input focus forwarding. Therefore a Mouse off a
974: async port will always report its data to the process no matter what
975: display it was started on. If more that one process opens an async mouse
976: they will compete for data from the mouse.
977: .sp 1
978: .TS
979: center allbox;
980: cb s s s s
981: c c c c c
982: l l c c l
983: .
984: Mouse Input Devices
985: _
986: Protections Owner Major Minor Device
987: crw-rw-rw- root 15, 0 /dev/ms
988: crw-rw-rw- root 15, 1 /dev/msaed
989: crw-rw-rw- root 15, 2 /dev/msmono
990: crw-rw-rw- root 15, 3 /dev/msapa8
991: crw-rw-rw- root 15, 4 /dev/msapa16
992: crw-rw-rw- root 15, 5 /dev/msapa8c
993: .TE
994: .PP
995: The
996: .ul
997: system mouse
998: and
999: .ul
1000: serial port mice
1001: drivers are essentially the same as you find in normal UNIX. These drivers
1002: hook into the emulator package through a user selecting a
1003: special line discipline. This line discipline
1004: filters the mouse data and then passes a generic
1005: data packet to the user through normal read system calls
1006: or calls the user specified emulator with the data packet.
1007: This line discipline is explained in the manual page for
1008: .ul
1009: tty_tb(4).
1010: .NH
1011: The Emulator Package RoadMap
1012: .PP
1013: The following tables briefly explains the files that make up the emulator
1014: package. The tables are split up the different parts that
1015: make up the emulator package according to functionality
1016: Each table state what that functionality is and where the files can be
1017: found as well as a description of what can be found in that file.
1018: Tables with a column marked
1019: .ul
1020: User
1021: distinguishes between purely kernel files
1022: and user/kernel shared include files. This indicates what files a user
1023: should include to get at the basic emulator functions and any particular
1024: emulator now available.
1025: .bp
1026: .TS
1027: expand allbox;
1028: cb s s
1029: cb s s
1030: c c c
1031: l c ltw(4i)
1032: .
1033: Emulator Control Files
1034: _
1035: "/sys/machinecons"
1036: File User Description
1037: cons.c no T{
1038: Console Driver, routes requests to appropriate emulator and its Input/Output
1039: device or to the emulator controller.
1040: Console driver is also responsible for console message forwarding.
1041: T}
1042: consdefs.h no T{
1043: This file contains hardware interface information about system input
1044: devices. Emulators as well as device dependent routines use this to
1045: interface with each other and the hardware.
1046: T}
1047: consio.h yes T{
1048: Defines for what displays and screen controls/flags are available. The
1049: IOCTL commands and structure for screen_control are in here. This file is
1050: indirectly included by screen_conf.h.
1051: T}
1052: consvars.h no T{
1053: Emulator control variables are declared here.
1054: T}
1055: bus.c no T{
1056: I/O Bus control driver, which allows access to the I/O bus on a per process
1057: basis. Window managers which need to get directly at the display from user
1058: space should open "/dev/bus".
1059: T}
1060: screen_conf.c no T{
1061: Where all the displays and emulators are configured for the system. This
1062: file also contains the emulator control routines discussed in "What the
1063: Emulator Package gives you".
1064: T}
1065: screen_conf.h yes T{
1066: Where all the structures, defines, and macros for the emulator package
1067: live. This contains all the macros for an emulator to interface with the
1068: Device Dependent routines as well as the IOCTL information for the user to
1069: interface with the Emulator Package.
1070: T}
1071: .TE
1072: .TS
1073: expand box;
1074: cb s s
1075: cb s s
1076: c | c | c
1077: l | c | ltw(4i)
1078: .
1079: Emulators
1080: =
1081: "/sys/machinecons"
1082: _
1083: File User Description
1084: aed.c no T{
1085: AED raw microcode graphic emulator.
1086: T}
1087: aeddefs.h \^ \^
1088: _
1089: buf_emul.c no T{
1090: Buffering emulator, which saves messages sent to display and then flushes
1091: them when the output emulator is changed.
1092: T}
1093: _
1094: ibm_emul.c no T{
1095: IBM3101 output emulator. Takes a considerable subset of IBM3101 commands
1096: defined in tcap.
1097: T}
1098: mono_tcap.h \^ \^
1099: _
1100: kbd_emul.c no T{
1101: A smarter keyboard emulator which allows mapping of key codes to a character
1102: stream.
1103: T}
1104: kbd_emul.h \^ \^
1105: kbde_codes.h \^ \^
1106: _
1107: std_emul.c no T{
1108: Standard input and output emulator routines. A straight key code to
1109: character mapping is done on input and the raw characters are sent to the
1110: display on output. This output emulator is used for displays which perform
1111: their own emulations.
1112: T}
1113: std_emul.h \^ \^
1114: _
1115: x_emul.c no T{
1116: X window system input emulator. This queues up keyboard and mouse events
1117: into a shared memory area between kernel and user. This emulator also has
1118: a variety of IOCTLs for controlling the locator on a display, as well as
1119: performing other X related functions (e.g. tracking the cursor, etc.).
1120: T}
1121: xio.h yes T{
1122: X dependent structures and defines for kernel and usr process.
1123: T}
1124: _
1125: qevent.h yes T{
1126: Event Queue structures and defines used by only the X emulator currently.
1127: T}
1128: .TE
1129: .bp
1130: .TS
1131: expand allbox;
1132: cb s s
1133: cb s s
1134: c c c
1135: l c ltw(4i)
1136: .
1137: New/Changed Line Discipline files
1138: =
1139: "/sys/sys" and "/sys/h"
1140: _
1141: File User Description
1142: tty_conf.c no T{
1143: Line discipline configure file.
1144: T}
1145: tty.h yes T{
1146: Line discipline structures and defines.
1147: T}
1148: =
1149: tty_tb.c no T{
1150: Normal tablet line discipline changed to support system/serial type mice also.
1151: Also changed for forwarding data packets to input emulator if specified.
1152: T}
1153: tbdefs.h no T{
1154: Tablet/Mouse generic data packet structures and defines.
1155: T}
1156: tbioctl.h yes T{
1157: IOCTL commands and structures.
1158: T}
1159: .TE
1160: .TS
1161: expand allbox;
1162: cb s
1163: cb s
1164: c c
1165: l ltw(4i)
1166: .
1167: Low Level Output Display Dependent Files
1168: _
1169: "/sys/machinecons"
1170: File Description
1171: aed_tty.h T{
1172: Macros and defines for interfacing with the Glass TTY microcode for the
1173: AED display.
1174: T}
1175: aed_tty_mcode.h T{
1176: Glass TTY microcode for download to the AED display.
1177: T}
1178: aedloc.c T{
1179: AED locator low level device dependent routines.
1180: T}
1181: aedtty.c T{
1182: AED Glass TTY low level device dependent routines.
1183: T}
1184: apa16loc.c T{
1185: APA16 locator low level device dependent routines.
1186: T}
1187: apa16tty.c T{
1188: APA16 Glass TTY low level device dependent routines.
1189: T}
1190: apa16tty.h T{
1191: APA16 device dependent structures and define.
1192: T}
1193: apa16tty_font.h T{
1194: APA16 Font for Glass TTY emulation.
1195: T}
1196: apa8cloc.c T{
1197: APA8 Color locator low level device dependent routines.
1198: T}
1199: apa8ctty.c T{
1200: APA8 Color Glass TTY low level device dependent routines.
1201: T}
1202: apa8ctty.h T{
1203: APA8 Color device dependent structures and define.
1204: T}
1205: apa8loc.c T{
1206: APA8 locator low level device dependent routines.
1207: T}
1208: apa8tty.c T{
1209: APA8 Glass TTY low level device dependent routines.
1210: T}
1211: apa8tty.h T{
1212: APA8 device dependent structures and define.
1213: T}
1214: apa8tty_font.h T{
1215: APA8 and APA8 Color Font for Glass TTY emulation.
1216: T}
1217: apa_fontblt.c T{
1218: Generic routines for font manipulation on APA displays.
1219: T}
1220: apa_structs.h T{
1221: Generic structures and defines for font manipulation on APA displays.
1222: T}
1223: apaaed.h T{
1224: Structures and defines for dealing with the AED as an APA display.
1225: T}
1226: mono.c T{
1227: Monocrome Glass TTY low level device dependent routines.
1228: T}
1229: monocons.h T{
1230: Monocrome device dependent structures.
1231: T}
1232: monodefs.h T{
1233: Monocrome device dependent defines.
1234: T}
1235: .TE
1236: .bp
1237: .TS
1238: expand allbox;
1239: cb s
1240: cb s
1241: c c
1242: l ltw(4i)
1243: .
1244: Low Level Keyboard Device Dependent Routines
1245: _
1246: "/sys/machinecons"
1247: File Description
1248: keyboard.c System Keyboard hardware routines.
1249: keyboard.h System Keyboard hardware structures and defines.
1250: .TE
1251: .sp 1
1252: .TS
1253: expand allbox;
1254: cb s s
1255: cb s s
1256: c c c
1257: l c ltw(4i)
1258: .
1259: System and Serial Mouse Device Drivers
1260: _
1261: "/sys/machineio"
1262: File User Description
1263: asy.c no T{
1264: Serial asynchronous driver, supports 4 port board and
1265: Parallel/Serial board.
1266: T}
1267: asyregs.h no T{
1268: Serial hardware structures and defines.
1269: T}
1270: mouse.c no T{
1271: Driver for system mouse.
1272: T}
1273: mouseio.h yes T{
1274: System Mouse structures and defines. Also includes IOCTL controls/defines
1275: for user processes.
1276: T}
1277: mousereg.h no T{
1278: System mouse driver declarations.
1279: T}
1280: psp.c no T{
1281: System (Planar) Serial Port driver.
1282: T}
1283: pspreg.h no T{
1284: Planar Serial Port hardware structures and defines.
1285: T}
1286: .TE
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.