Re: GGI, EGCS/PGCC, Kernel source

Theodore Y. Ts'o (tytso@MIT.EDU)
Fri, 27 Feb 1998 14:49:06 -0500

Date: Fri, 27 Feb 1998 14:38:17 -0500 (EST)
From: Jason McMullan <>
Content-Type: text

IF we were using the hypothetical N_KEYBOARD discipline, the
tty would be treaded like any other input device, and send
all it's events to the `input_stack' device. The input_stack
takes care of the mapping between input devices and VTs.

The keyboard mapper ITSELF handles the ALT-Fx and CTRL-ALT-DEL
cases, and calls the appropriate handlers.

We need to be very careful about our terms here, please, or we will just
confuse everybody. A tty has a very well defined meaning today --- it
is a serial tty, or a pseudo-tty, or a console tty, whose user-level
interfaces are defined by POSIX and which are implemented by
drivers/char/tty_io.c, drivers/char/tty_ioctl.c, and

A tty doesn't have "events". A keyboard may have events, which is
currently handled by drivers/char/keyboard.c. Those events are today
translated into ASCII or UTF-8 in the drivers/char/keyboard.c, which
implements multiple tty->driver abstract interface. The current
keyboard driver dos the keycode mapping and the dispatching to the
correct instantiation of the tty->driver abstract interface. This
driver then sends the characters to the tty line discpline, which is
usually the N_TTY line discipline, implemented by drivers/char/n_tty.c.

Now, I've been explicit about defining my terms. Would you like to be
specific about defining yours, please, and be concrete about where all
of these "input_stack" and "keyboard mappers" might live? I can see
problems already, but I don't want to make assumptions about how you
think the brave new GGI world will work.

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to