Messages in this thread | | | From | Rick Hohensee <> | Subject | comments on compose keys | Date | Thu, 7 Oct 1999 07:45:22 -0400 (EDT) |
| |
It looks like MAX_DIACR in ../linux/include/linux/keyboard.h, or rather, the kernel behavior defined by it, is off by one. It appears that 255 is the effective max when the stock value is 256. This is in terms of the 0x00004B4B KDSKBDIACR ioctl. My guess is that the off-by-one-ness isn't indicative of anything less trivial, but mentioning it is a prelude to suggesting you bump that value to at least 512 or so. The reason is I suggest a different arrangement for the default compose keys. 256, one more than is available normally, allows a full hexadecimal entry method, a Compose key hexpad. It has long annoyed me that that directness is absent, when it was present on much older machines and "toy" machines like the c64. The c64 didn't have an actual hexpad, but there was some key combination for all 256 bytes, which does not appear to be the case with a stock Linux. A hexpad is utterly general, and regular. The various sophisticated interfaces Linux provides other than this are great, but are not so great as to validate losing the things they are built on.
The syntax of the Compose mechanism in loadkeys can't seem to do the decimal byte values 0 or 10, and there don't seem to be any kernel keyboard driver action names for the hex values 0x80 through 0x9f. With a large number of accent table slots, the usual regional characters can be supported in addition to the hexpad interface. Also, in 1999 terms, compose key slots are very cheap. As cheap as they are, I'll probably do upper and lowercase A-F's, plus move the ISO-blabla keys up above that.
In other words, a hexpad is pure mechanism, where other interfaces have a policy component. A hexpad is one of those things you hope to never need, but you don't want to be without. The userspace implementation that caused me to bump into MAX_DIACR is Left As An Excersize To The Reader.
Rick Hohensee cLIeNUX hexhead
About a previous error, in my character frequencies post, Jes Sorensen pointed out that there are 8-bit characters in the kernel sources, and indeed there do seem to be, at least in the kernel defkeymap.c or whatever the name is. I suspect the basic proportions of the characters in that post were close though.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |