lkml.org 
[lkml]   [1999]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectcomments on compose keys
Date

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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.030 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site