: UTF-8 has nothing to do with my situation.
: >Maybe you can clarify what you want to do, and why the current setup
: >is unfortunate for your purposes?
: OK, sorry. I'm writing a universal keyboard library, which will sit on top
: of the linux console, X, or some random terminal and tell the program very
: specifically what key was pressed (vaguely like X's interface, but structured
: for more versatility.) It natively supports all of ISO-10646 (even portions
: outside the BMP), so I would like to be able to read a full keymap from
: the kernel and then switch into VC_MEDIUMRAW mode to use it as well as
: possible. Of course I can go into VC_UNICODE mode to read the keymap, but
: that strikes me as a silly requirement. The keyboard map doesn't depend
: on the mode, so why should the version of it exported to userspace via
: the GD[GS]KBENT ioctls?
Well, the keyboard map does depend on the mode - at least conceptually.
The parts of the keymap that are invisible when you are not in VC_UNICODE
mode are precisely the parts that generate UTF-8 code, which is probably
meaningless to a non-Unicode-aware application.
(And indeed, one might argue that there should be a test for VC_UNICODE
before UTF-8 is generated; if I recall correctly, I left the test in a comment,
since it is ugly to generate error messages from the keyboard driver.)
Since your application is Unicode-aware, it takes only one ioctl to tell
that to the kernel.
Andries