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
drivers/char/n_tty.c.
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 majordomo@vger.rutgers.edu