On Sun, 26 Jul 1998 Andries.Brouwer@cwi.nl wrote:
> The patch says
>
> + /* ++Geert: non-PC keyboards may generate keycode zero */
> +#if !defined(__mc68000__) && !defined(__powerpc__)
> /* assignment to entry 0 only tests validity of args */
> if (!i)
> break;
> +#endif
>
> but that is wrong, and this part of the patch should be reverted.
Can we please keep it like this for 2.2? Reverting it will break at least
Debian 2.0.
Hmm. Hardly a convincing argument. "Let us introduce a bug in the
kernel to compensate for a bug we introduced in Debian 2.0."
> (Or, without special value, some new ioctls have to be introduced.
I favor the new ioctl.
Very good then. Let us add a new pair of ioctls, now, immediately,
so that this part of the kernel becomes again (i) correct, and
(ii) architecture independent.
In 2.3.x we can continue our holy wars _and_ find a
solution for the `my keyboard has more than 128 (127?) keys' problem.
Yes, such keyboards exist!
It is easy enough to solve: instead of allocating chunks of size NR_KEYS=128,
we allocate chunks of size MAX_NR_OF_KEYS. Add an ioctl to get and set
MAX_NR_OF_KEYS, and all works again. We might do that immediately as well,
although I regard this as low priority.
(There is another thing that one might want to look into.
Roughly speaking the keyboard driver is extremely flexible and general,
willing to do almost anything, but in the area of dead keys there is
only a short fixed list of possible dead keys (I think 6 of them),
and the past few years I have repeatedly met people who needed more.
Especially for Vietnamese.)
> The special value is used for things like the control over
> allocation and deallocation of keymaps. Only loadkeys and dumpkeys
> know about it.)
And they were patched a very long time ago, too...
Yes, `patched' in the sense where correctness and functionality
is lost, but things still work more or less.
Let us do it right.
Date: Mon, 27 Jul 1998 16:09:29 -0700 (PDT)
From: Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU>
To: Geert.Uytterhoeven@cs.kuleuven.ac.be
Cc: linux-m68k@lists.linux-m68k.org
Subject: RE: L68K: vt.c in 2.1.111 (fwd)
>But the present keyboard and console utilities assume that
>keycodes lie in the interval 1-127, and the value 0 is used
>for special purposes.
Remind me: what special purpose was this?
The Linux kernel uses 7 keymaps by default.
Most user keymaps use between 6 and 16 keymaps (with numbers in 0-15).
Some use more (like gr.map:keymaps 0-2,4-6,8-9,12,64-66,68-70,72-73,76).
Some use very much more (everybody who inputs Unicode at the keyboard).
Now 256 keymaps take 128k, which is too much to waste, when almost
nobody needs it. So, 7 keymaps (3.5k) are compiled in, and the other
keymaps are allocated dynamically.
The utilities loadkeys and dumpkeys use entry 0 of the keymaps to
ask the kernel whether that keymap has been allocated, or to
request allocation or deallocation.
The kernel itself uses entry 0 to keep track of whether the keymap
was allocated (so that it can be freed) or was compiled in.
**NOTE** The patch I objected against (because it is a bug, introduced
out of laziness, or possibly in order to rescue a buggy Debian 2.0)
has as side effect that the kernel loses this knowledge about a keymap's
origin, thus introducing a possible memory leak. This means that anybody
at the console can kill the kernel by asking for sufficiently many
new keymaps. On the other hand, it means that anybody at the console
can make the kernel free some memory that was never allocated.
In other words, we must not say `leave this for 2.3', but correct
things now.
[Maybe Geert can write the required patch, or, if he is too busy
with the console side of the keyboard/console system, I might do so.
Probably we can keep this to private email until we are satisfied
with the produced code.]
Andries
-
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.altern.org/andrebalsa/doc/lkml-faq.html