In 2.4, Japanese 86/106 keyboards used to be able to generate
backslash and pipe characters (around ll. 367 in
linux-2.4.21/drivers/char/pc_keyb.c), but the rewritten AT
keyboard driver linux-2.6.0-test1/drivers/input/keyboard/atkbd.c
does not seem to have corresponding support for that key. As a
result, the key seems to be dead and I cannot type '|' on such a
keyboard from Linux console (it works OK in X Window but that is
expected).
For your reference, here is some comments in the 2.4 PC keyboard
driver that I think is relevant.
ll.367-
...
} else if (scancode >= SC_LIM) {
/* This happens with the FOCUS 9000 keyboard
Its keys PF1..PF12 are reported to generate
55 73 77 78 79 7a 7b 7c 74 7e 6d 6f
Moreover, unless repeated, they do not generate
key-down events, so we have to zero up_flag below */
/* Also, Japanese 86/106 keyboards are reported to
generate 0x73 and 0x7d for \ - and \ | respectively. */
/* Also, some Brazilian keyboard is reported to produce
0x73 and 0x7e for \ ? and KP-dot, respectively. */
*keycode = high_keys[scancode - SC_LIM];
...
On Sat, Jul 19, 2003 at 03:44:11AM -0700, [email protected] wrote:
> In 2.4, Japanese 86/106 keyboards used to be able to generate
> backslash and pipe characters (around ll. 367 in
> linux-2.4.21/drivers/char/pc_keyb.c), but the rewritten AT
> keyboard driver linux-2.6.0-test1/drivers/input/keyboard/atkbd.c
> does not seem to have corresponding support for that key. As a
> result, the key seems to be dead and I cannot type '|' on such a
> keyboard from Linux console (it works OK in X Window but that is
> expected).
>
> For your reference, here is some comments in the 2.4 PC keyboard
> driver that I think is relevant.
>
> ...
> } else if (scancode >= SC_LIM) {
> /* This happens with the FOCUS 9000 keyboard
> Its keys PF1..PF12 are reported to generate
> 55 73 77 78 79 7a 7b 7c 74 7e 6d 6f
> Moreover, unless repeated, they do not generate
> key-down events, so we have to zero up_flag below */
> /* Also, Japanese 86/106 keyboards are reported to
> generate 0x73 and 0x7d for \ - and \ | respectively. */
> /* Also, some Brazilian keyboard is reported to produce
> 0x73 and 0x7e for \ ? and KP-dot, respectively. */
>
> *keycode = high_keys[scancode - SC_LIM];
>
> ...
Ha - really long ago I wrote that..
Yes, for 2.5 things are much more involved, but I suppose that
all will be well if you add the line
keycode 183 = backslash bar
to your keymap.
Andries
>>>>> "AB" == Andries Brouwer <[email protected]> writes:
AB> Ha - really long ago I wrote that..
AB> Yes, for 2.5 things are much more involved, but I suppose that
AB> all will be well if you add the line
AB> keycode 183 = backslash bar
AB> to your keymap.
Thanks, it really was a long ago. With the above included in
drivers/char/defkeymap.map and regenerating defkeymap.c_shipped
with loadkeys (kbd-1.08 recompiled with include/linux/keyboard.h
that comes with 2.6 kernel), things started work again.
Is there a reason not to include the above "keycode 183" line in
the shipped source (both defkeymap.map and defkeymap.c_shipped)?
The 2.6 kernel without it can be seem as a feature degradation
from 2.4 for 86/106 keyboard users, and I would like to know if
there is a case where having that line hurts. Is "keycode 183"
generated for completely different characters on other national
keyboards, and having that line is a feature degradation for
users of such keyboards? I have access to only 101, 86, and 106
keyboards so I cannot test this myself. Or maybe there are
other reasons to leave the default keymap as minimal as it
currently is in 2.6 tree?