--- Denis Barbier <[EMAIL PROTECTED]> wrote: > I have another question about UTF-8 and kbd: some keymaps are defined > twice, with Unicode notation and numerical (or litteral) notation, like > mk-utf.map and mk-cp1251.map. Since Unicode notation is needed to > input non-ASCII characters, all keymaps will sooner or later provide > a -utf variant. But why is Unicode notation handled in a different > manner by loadkeys? This distinction could be made depending on > KDGKBMODE ioctl but not on input format so that a single keymap can > be used.
In reading keymaps man pages, I naturally assume that these text files are utf-8, and that international characters can be used in <keysym> i.e. "action" positions, so I don't know exactly what you mean by /unicode/ notation. Is that some kind of ascii notation used to represent unicode? Elvis I have some questions about keymaps myself : 1) Man page of LOADKEYS BUGS "The keyboard translation table is common for all the virtual consoles, so any changes to the keyboard bindings affect all the virtual consoles." :-( This is not a bug; it is a design defect. Each virtual keyboard needs its own keymap which translates keycodes (= modifier, key, event} into characters. 2) Man page of DUMPKEYS My cygwin does not respond to any of the keymaps commands, but I haven't checked my PATH variable (yet). 3) Virtual Consoles and xterms coexist! "You can even run a complete X session(=display?) in each console. The X Window System will use the virtual console 7 by default. So if you start X and then switch to one of the text-based virtual consoles, you can go back again to X by typing Alt-F7." O'Reilly, Running Linux, 3rd ed. 1999, pg. 94 "When X is started, it opens the first unused console [unused? /dev/console as a clone driver?]. While X is running, you can use Ctrl-Alt-Fn to switch to VTn. When X finishes, it will return to the original console [huh?]" http://www.tldp.org/HOWTOP/Keyboard-and-Console-HOWTO-13.html Therefore, a) 'virtual consoles' must emulate a graphical terminal. (xterms emulate vt100's, character-mode terminals, so you could not run an instance of X in an xterm, but it looks like you can (and do!) run X in a virtual console.) Hypothesis: you should also be able to run an X server as an X client in an X window, since each window is a graphical terminal emulator. Only the interfaces are different. I imagine the second, nested version of X, would open an X window using the xlib protocol. b) 'vterms(=virtual consoles)' and 'xterms' must be able to coexist. <notes> Tell me if you like this terminology: /*naive_keyboard.h*/ // I thought C++ enums introduced a new namespace. This is really ugly: namespace mod {enum {shift=0x8000, ctrl=0xc00, alt=0xe00}; } // Too bad I can't use the term /break/ in this context: namespace event {enum {make=0x0, brk=0x0080}; } // Then, a list of keycodes... namespace key {enum {ESC=0x01, k1=0x02, k2=0x03, k3=0x04, k4=0x05, k5=0x06, k6=0x07, k7=0x08, k8=0x09, k9=0x0a, k0=0x0b, minus=0x0c, equal=0x0d, BS=0x0e, tab=0x0f, Q=0x10, W=0x11, E=0x12, R=0x13, T=0x14, Y=0x15, U=0x16, I=0x17};} //etc //scancodes const int q_make = key::Q | event::make; const int q_break = key::Q | event::brk; // the Q key (code) const int q_key = q_make; // Composite keys: const int q_shift = mod::shift | q_key; const int q_ctrl = mod::ctrl | q_key; const int q_alt = mod::alt | q_key; const int q_ctrl_alt = mod::ctrl | mod::alt | q_key; "Composite Keys" The <Q> key can be represented by the make code(=0x10 | 0x00). <Shift-Q> is a /*composite*/ key being composed of <Shift> and <Q> keys (=0x8000 | 0x0010). <Ctrl-Alt-Q> = 0xc00 | 0xe00 | 0x0000 | 0x0010; The keyboard driver translates real keyboard scancodes into integer-valued "composite keys" (=keysyms in some idioms), which are more easily mapped to (utf-8) characters. X and Microsoft Windows do it this way. Users can change keyboard map in midstream(=line) by using an <Alt> key combination, so you can't replace a keyboard map as a module in a Stream. A composite keycode would contain bits set corresponding to the state of the keyboard. Careful, the CapsLock key changes the state of each (virtual) keyboard. X Keyboard events (unlike console scan codes) contain not only <make>, <break> events, but they also pass along the state of the keyboard determined by the modifier keys down at the time. Applications not interested in <break> events can ignore them, but they have to look at the entire keycode to determine the value of the key i.e. they must consider the modifier bits. (keycode is part of scancode in PC terminology.) Keyboard events are translated into characters by a conversion function. (naturally :) This function looks at a sequence of "dead" keys before outputting an accented character. Therefore: /*All keys are "dead" keys until they emit a character.*/ Traditional terminals send (ascii) characters to the tty driver in the host, so the keyboard logic (=event processing) was part of the terminal. It makes no sense to translate ascii characters into utf-8 characters in the tty. It must be done as part of the terminal emulator(=virtual console). There is significant functional overlapping between virtual consoles and x terminals. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
