keyboard

I have a microsoft (bleah) "internet keyboard" attached to my G3.
None of the new 19 keys works. When I press them it writes:

Aug 15 15:56:35 Jay kernel: keyboard.c: can't emulate rawmode for keycode 165

I see that there are some unused codes in the translation table in
usb/keybdev.c. May I use them to map the new keys ?

Bye.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

I have a microsoft (bleah) "internet keyboard" attached to my G3.
None of the new 19 keys works. When I press them it writes:

Aug 15 15:56:35 Jay kernel: keyboard.c: can't emulate rawmode for keycode 165

I see that there are some unused codes in the translation table in
usb/keybdev.c. May I use them to map the new keys ?

Big win if all of these keys produce the same keycode :-)

You can solve your problem much easier with loadkeys and a tailored
console keymap. Why pollute the kernel with that stuff (except for the
learning experience)?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Aug 15 15:56:35 Jay kernel: keyboard.c: can't emulate rawmode for keycode
165

I see that there are some unused codes in the translation table in
usb/keybdev.c. May I use them to map the new keys ?

Big win if all of these keys produce the same keycode :-)

You can solve your problem much easier with loadkeys and a tailored
console keymap.

No, I can't. mac_keyb.c uses a byte to store the pressed key. 1 bit is used
for pressed/released flag, so key codes range is 1-127. That special keys
have a code > 127 so currently they're not mapped at all.
I must change the kernel to remap that codes to something < 128.

Or perhaps I'll fix it by allowing int16_t keycodes just like on peecees.

Bye.
    Giuliano Pochini ->)|(<- Shiny Corporation {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

I see that there are some unused codes in the translation table in
usb/keybdev.c. May I use them to map the new keys ?

Big win if all of these keys produce the same keycode :-)

Ehm, no. keypress code is different, but keyrelease code if 180
for all of them. What a mess.


Bye.
    Giuliano Pochini ->)|(<- Shiny Corporation {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

You can solve your problem much easier with loadkeys and a tailored
console keymap.

No, I can't. mac_keyb.c uses a byte to store the pressed key. 1 bit is used
for pressed/released flag, so key codes range is 1-127. That special keys
have a code > 127 so currently they're not mapped at all.

So it's a more generic problem ...

I must change the kernel to remap that codes to something < 128.

Or perhaps I'll fix it by allowing int16_t keycodes just like on peecees.

The latter, if at all possible (because that allows for using the console
keymap tools again if I'm not mistaken).

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Or perhaps I'll fix it by allowing int16_t keycodes just like on peecees.

The latter, if at all possible (because that allows for using the console
keymap tools again if I'm not mistaken).

?  I don't know anything about that. Please tell me more.

Bye.
    Giuliano Pochini ->)|(<- Shiny Corporation {AS6665} ->)|(<-


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

quoted

Or perhaps I'll fix it by allowing int16_t keycodes just like on peecees.

The latter, if at all possible (because that allows for using the console
keymap tools again if I'm not mistaken).

?  I don't know anything about that. Please tell me more.

Come again? You said you could not use the user space keymap tools
(loadkeys) because only keycodes < 127 are currently used. You offered to
fix the kernel side problem by allowing for 16 bit keycodes, and I said
fine, do that if possible, it might solve the loadkeys problem in the
process. So where's the misunderstanding?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/