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.
Indeed, the keyboard model is:
- the hardware generates scancodes
- sequences of scancodes are parsed into keycodes
- (further processing)
The value of scancodes cannot be controlled by the kernel -
they are hardware-generated. However, the value of the keycodes
is purely conventional (for example, the Linux kernel and X use
different keycodes). So, a comment that keyboards may generate
keycode zero is necessarily false.
Of course, in many situations the parsing alluded to above
is just the identity transformation (for i386: "For 1-88 keycode
equals scancode").
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.
If on some architectures the hardware generates a 0 for some key
then the keyboard driver for such hardware should return some
different keycode (say 127) for that key.
On the other hand, if people consider this messy - maybe it is
a pity to destroy scancode == keycode for architectures where
this nice equality is feasible - then vt.c and the keyboard utilities
must be adapted to use e.g. 127 as special value instead of 0;
however, 127 is presently used on Microsoft keyboards, so such a
change would affect many people.
(Or, without special value, some new ioctls have to be introduced.
The special value is used for things like the control over
allocation and deallocation of keymaps. Only loadkeys and dumpkeys
know about it.)
Whatever solution is preferred, it should not have
#if defined(architecture)
in vt.c.
Andries
(Not on linux-kernel; cc to me if you reply.)
-
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