Messages in this thread | | | Date | Mon, 15 Apr 1996 18:52:28 -0600 (CST) | From | Aaron Ucko <> | Subject | Re: KDGKBENT |
| |
> Yes, I understand all that. What does this have to do with having to > set the mode to VC_UNICODE just to read a complete keymap? > ... > X in particular supports non-ISO-8859-1 characters anyway > (albeit not via Unicode). > >I do not understand what you can have in mind. >The keyboard driver knows nothing about ISO-8859-1. >Many people are using it with ISO-8859-2, for example, but >also much more exotic character sets are in use. > >The distinction is not ISO-8859-1 versus non-ISO-8859-1, but >single-byte versus UTF-8.
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? > >Andries
-- Aaron Ucko (ucko@vax1.rockhurst.edu; finger for PGP public key) | httyp! "That's right," he said. "We're philosophers. We think, therefore we am." -- Terry Pratchett, _Small Gods_ | Geek Code 3.1 [for explanation, finger hayden@mankato.msus.edu]: GCS/M/S/C d- s: a18 C++(+++)>++++ UL++>++++ P++ L++>+++++ E- W(-) N++(+) o+ K- w--- O M@ V-(--) PS++(+++) PE- Y(+) PGP(+) t(+) !5 X-- R(-) tv-@ b++(+++) DI+ !D-- G++(+++) e->+++++(*) h!>+ r-(--)>+++ y?
| |