Keycodes for the new input layer

DISCUSSION Derek Homeier 2 participants 9 messages Jul 11, 2000 – Jul 14, 2000 1 message not in the archive Linux for power macintosh

lore

Share & tools

lore

Derek Homeier

author

2000-07-11 17:48 UTC #1 lore raw

In reply to a message not in the archive

One more cheers to the backport of the new USB input layer! Finally, I'm able to use the trackpad and the usbmouse with wheel simultaneously in X, and together with gpm. I have a couple of minor problems with the configuration of the keys on my 101 Powerbook (Lombard), though:

How do I figure out the keycodes for the "keypad"-enter key (between the spacebar and the right option key, marked with a '_^')? I like this one best for mousebutton emulation and mapped button 3 to kp_enter and button 2 to fn-kp_enter. These had console keycodes 58 and 110. With the new kernel, button 2 defaults to the fn-key alone (which makes it useless for anything else) and, I think, option.
The only "enter" or "return" keys defined in input.h are KEY_ENTER=28 and KEY_KPENTER=96, but when I print 96 to /proc/sys/dev/mac_hid/mouse_button3_keycode, button 3 is emulated by the fn-return combination (which is also marked by '_^').
I recall that this other enter key seemed to be lost already in previous 2.3 kernels, but I'd really like to get it back. Currently, this enter and fn-enter are performing like the standard return key and no key at all, respectively.
Another thing that puzzles me is that I can print 100 (KEY_RIGHTALT) to mouse_button3_keycode. The left and right option keys on the PB keyboard are indistinguishable, but with this setting, fn-opt is working as mouse-3, and opt is still working normally. If fn-opt is not mapped to mouse-3, however, it always gives the same keycodes as opt, so I found no way yet to make it a regular right_alt or AltGr key. Is there a way to make it generate a different keycode?

Thanks i.a.,
Derek

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

Franz Sirl

2000-07-11 20:44 UTC #2 lore raw

Quoted 18 lines · Derek Homeier

One more cheers to the backport of the new USB input layer! Finally, I'm able to use the trackpad and the usbmouse with wheel simultaneously in X, and together with gpm. I have a couple of minor problems with the configuration of the keys on my 101 Powerbook (Lombard), though:
How do I figure out the keycodes for the "keypad"-enter key (between the spacebar and the right option key, marked with a '_^')? I like this one best for mousebutton emulation and mapped button 3 to kp_enter and button 2 to fn-kp_enter. These had console keycodes 58 and 110. With the new kernel, button 2 defaults to the fn-key alone (which makes it useless for anything else) and, I think, option.
The only "enter" or "return" keys defined in input.h are KEY_ENTER=28 and KEY_KPENTER=96, but when I print 96 to /proc/sys/dev/mac_hid/mouse_button3_keycode, button 3 is emulated by the fn-return combination (which is also marked by '_^').
I recall that this other enter key seemed to be lost already in previous 2.3 kernels, but I'd really like to get it back. Currently, this enter and fn-enter are performing like the standard return key and no key at all,

Quoted 8 lines

respectively.
Another thing that puzzles me is that I can print 100 (KEY_RIGHTALT) to mouse_button3_keycode. The left and right option keys on the PB keyboard are indistinguishable, but with this setting, fn-opt is working as mouse-3, and opt is still working normally. If fn-opt is not mapped to mouse-3, however, it always gives the same keycodes as opt, so I found no way yet to make it a regular right_alt or AltGr key. Is there a way to make it generate a different keycode?

Hmm, what kernel are you using? the binary on Ben's page or a selfcompiled one? Old mode (kernel_sends_linux_keycodes==0) or new mode (kernel_sends_linux_keycodes==0)?

The Fn key is not really handled right now and probably requires more kernel support for the key combos not handled in HW. Anyone has a list of these combos?

Franz.

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

Derek Homeier

author

2000-07-12 10:41 UTC #3 lore raw

Quoted 28 lines · Franz Sirl

Quoted 18 lines · Derek Homeier
One more cheers to the backport of the new USB input layer! Finally, I'm able to use the trackpad and the usbmouse with wheel simultaneously in X, and together with gpm. I have a couple of minor problems with the configuration of the keys on my 101 Powerbook (Lombard), though:
How do I figure out the keycodes for the "keypad"-enter key (between the spacebar and the right option key, marked with a '_^')? I like this one best for mousebutton emulation and mapped button 3 to kp_enter and button 2 to fn-kp_enter. These had console keycodes 58 and 110. With the new kernel, button 2 defaults to the fn-key alone (which makes it useless for anything else) and, I think, option.
The only "enter" or "return" keys defined in input.h are KEY_ENTER=28 and KEY_KPENTER=96, but when I print 96 to /proc/sys/dev/mac_hid/mouse_button3_keycode, button 3 is emulated by the fn-return combination (which is also marked by '_^').
I recall that this other enter key seemed to be lost already in previous 2.3 kernels, but I'd really like to get it back. Currently, this enter and fn-enter are performing like the standard return key and no key at all,
Quoted 8 lines
respectively.
Another thing that puzzles me is that I can print 100 (KEY_RIGHTALT) to mouse_button3_keycode. The left and right option keys on the PB keyboard are indistinguishable, but with this setting, fn-opt is working as mouse-3, and opt is still working normally. If fn-opt is not mapped to mouse-3, however, it always gives the same keycodes as opt, so I found no way yet to make it a regular right_alt or AltGr key. Is there a way to make it generate a different keycode?

Quoted 8 lines

Hmm, what kernel are you using? the binary on Ben's page or a selfcompiled one? Old mode (kernel_sends_linux_keycodes==0) or new mode (kernel_sends_linux_keycodes==0)?
The Fn key is not really handled right now and probably requires more kernel support for the key combos not handled in HW. Anyone has a list of these combos?

That was with Ben's precompiled kernel, but I have just rsynced the 2.2.17pre10-ben1 sources. The only differences are that the mouse buttons now are not emulated by anything by default (at least I could not find any key), the Fn key is not reported as an input event any longer (used to be xkb-code 80 with xev), and the second Enter is not recognized at all, neither w/ nor w/o Fn pressed. kernel_sends_linux_keycodes==1 does not change anything for the mousebuttons, but annoyingly sets META to Option (and of course resets the console map to US).

I have to correct the keycodes I gave for the ^ key:
_
^: 52, xkb keycode 60 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 characters: ""
_
Fn-^: 110, xkb keycode 118 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "

RET: 36, xkb keycode 44 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 characters: "

Fn-RET: 72, xkb keycode 84 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "

Both Opt and Fn-Opt are 58 (xkb 66).
(with 2.2.17pre9-benh1)
With 2.2.17pre10-benh1, syslog reports:

Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) pressed.
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) released.
     _

when ^ is pressed, and

Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) pressed.
Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) released.
       _

for Fn-^.

Thanks,
Derek

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

Franz Sirl

2000-07-12 11:25 UTC #4 lore raw

Quoted 41 lines · Derek Homeier

Quoted 6 lines · Franz Sirl
Quoted 5 lines · Derek Homeier
One more cheers to the backport of the new USB input layer! Finally, I'm able to use the trackpad and the usbmouse with wheel simultaneously in X, and together with gpm. I have a couple of minor problems with the configuration of the keys on my 101 Powerbook (Lombard), though:
Quoted 12 lines
Quoted 4 lines
How do I figure out the keycodes for the "keypad"-enter key (between the spacebar and the right option key, marked with a '_^')? I like this one best for mousebutton emulation and mapped button 3 to kp_enter and button 2 to fn-kp_enter. These had console keycodes 58 and 110.
Quoted 8 lines
With the new kernel, button 2 defaults to the fn-key alone (which makes it useless for anything else) and, I think, option.
The only "enter" or "return" keys defined in input.h are KEY_ENTER=28 and KEY_KPENTER=96, but when I print 96 to /proc/sys/dev/mac_hid/mouse_button3_keycode, button 3 is emulated by the fn-return combination (which is also marked by '_^').
I recall that this other enter key seemed to be lost already in previous 2.3 kernels, but I'd really like to get it back. Currently, this
enter and
Quoted 5 lines
Quoted 5 lines
fn-enter are performing like the standard return key and no key at all, respectively.
Another thing that puzzles me is that I can print 100 (KEY_RIGHTALT) to mouse_button3_keycode. The left and right option keys on the PB keyboard are indistinguishable, but with this setting, fn-opt is working as
mouse-3,
Quoted 10 lines
Quoted 4 lines
and opt is still working normally. If fn-opt is not mapped to mouse-3, however, it always gives the same keycodes as opt, so I found no way yet to make it a regular right_alt or AltGr key. Is there a way to make it generate a different keycode?
Hmm, what kernel are you using? the binary on Ben's page or a selfcompiled one? Old mode (kernel_sends_linux_keycodes==0) or new mode (kernel_sends_linux_keycodes==0)?
The Fn key is not really handled right now and probably requires more
kernel
Quoted 3 lines
support for the key combos not handled in HW. Anyone has a list of these combos?

Quoted 8 lines

That was with Ben's precompiled kernel, but I have just rsynced the 2.2.17pre10-ben1 sources. The only differences are that the mouse buttons now are not emulated by anything by default (at least I could not find any key), the Fn key is not reported as an input event any longer (used to be xkb-code 80 with xev), and the second Enter is not recognized at all, neither w/ nor w/o Fn pressed. kernel_sends_linux_keycodes==1 does not change anything for the mousebuttons, but annoyingly sets META to Option (and of course resets the console map to US).

It should be:

ALT = optionL
ALTGR = optionR

by default in most PC maps and the default kernel maps I think. I'll have an updated console-tools package ready later today, which will do it right for most Macs:

ALT = optionL
ALTGR = commandL or commandR

Quoted 22 lines

                                              _
I have to correct the keycodes I gave for the ^ key:
_
^: 52, xkb keycode 60 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 characters: ""
_
Fn-^: 110, xkb keycode 118 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "
RET: 36, xkb keycode 44 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 characters: "
Fn-RET: 72, xkb keycode 84 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "
Both Opt and Fn-Opt are 58 (xkb 66).
(with 2.2.17pre9-benh1)
With 2.2.17pre10-benh1, syslog reports:
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) pressed.
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) released.
     _

Quoted 6 lines

when ^ is pressed, and

Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) pressed.
Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) released.
       _

for Fn-^.

Ah, that's good information, just one question, what does the _^ key do in MacOS? I mean what can I do with this key in MacOS? Is it a modifier? A prefix? does it print characters?

Franz.

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

Derek Homeier

author

2000-07-12 11:49 UTC #5 lore raw

Quoted 4 lines · Franz Sirl

Quoted 3 lines · Derek Homeier
Quoted 1 line · Franz Sirl
On Tue, 11 Jul 2000, Derek Homeier wrote:

[snip]

Quoted 15 lines

Quoted 9 lines
Quoted 1 line
That was with Ben's precompiled kernel, but I have just rsynced the 2.2.17pre10-ben1 sources. The only differences are that the mouse buttons now are not emulated by anything by default (at least I could not find any key), the Fn key is not reported as an input event any longer (used to be xkb-code 80 with xev), and the second Enter is not recognized at all, neither w/ nor w/o Fn pressed. kernel_sends_linux_keycodes==1 does not change anything for the mousebuttons, but annoyingly sets META to Option (and of course resets the console map to US).
It should be:
ALT = optionL
ALTGR = optionR

Quoted 7 lines

by default in most PC maps and the default kernel maps I think. I'll have an updated console-tools package ready later today, which will do it right for most Macs:
ALT = optionL
ALTGR = commandL or commandR

I may disagree with a lot of people, but this does not seem right to me. On international keyboards you need Mode_switch for a lot of characters (as you'll certainly know ;-), which is usually bound to AltGr on PC-Hardware. Under MacOS, this is effected by Option-Key combinations, so for a fully MacOS-compatible keymap you need to have ALTGR bound to Option. Also I feel that the purpose of the Meta or ALT(L) on Unix is more similar to that of Cmd in MacOS, but that's rather my personal opinion. Of course, things do not become simpler by the fact that optionL and optionR are identical on most Mac keyboards. If it were possible to make Fn-Opt generate ALTGR (or vice-versa), this would add some flexibility.

Quoted 25 lines

Quoted 25 lines
                                              _
I have to correct the keycodes I gave for the ^ key:
_
^: 52, xkb keycode 60 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 characters: ""
_
Fn-^: 110, xkb keycode 118 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "
RET: 36, xkb keycode 44 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 characters: "
Fn-RET: 72, xkb keycode 84 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "
Both Opt and Fn-Opt are 58 (xkb 66).
(with 2.2.17pre9-benh1)
With 2.2.17pre10-benh1, syslog reports:
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) pressed.
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) released.
     _
when ^ is pressed, and

Quoted 9 lines

Quoted 4 lines
Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) pressed.
Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) released.
       _
for Fn-^.
Ah, that's good information, just one question, what does the _^ key do in MacOS? I mean what can I do with this key in MacOS? Is it a modifier? A prefix? does it print characters?

It does mostly, but not always, the same as the Return key on the main keyboard. For some applications, it behaves differently. In the Finder, e.g. hitting KP_Enter will let you edit the name of the selected file. I think under MacOS, there's no difference between Fn-Return and the dedicated _^ key on the PB keyboard, and the standard ADB keyboard only has one KP_Enter anyway.

I had another problem with the new input layer I forgot to mention:
Though I selected /dev/mouse (-> inputs/mice) as input device and imps2 as protocol, the mouse does not work in mol in the console mode.

HTH,
Derek

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

Franz Sirl

2000-07-12 12:30 UTC #6 lore raw

Quoted 29 lines · Derek Homeier

Quoted 4 lines · Franz Sirl
Quoted 3 lines · Derek Homeier
Quoted 1 line · Franz Sirl
On Tue, 11 Jul 2000, Derek Homeier wrote:
[snip]
Quoted 15 lines
Quoted 9 lines
Quoted 1 line
That was with Ben's precompiled kernel, but I have just rsynced the 2.2.17pre10-ben1 sources. The only differences are that the mouse buttons now are not emulated by anything by default (at least I could not find any key), the Fn key is not reported as an input event any longer (used to be xkb-code 80 with xev), and the second Enter is not recognized at all, neither w/ nor w/o Fn pressed. kernel_sends_linux_keycodes==1 does not change anything for the mousebuttons, but annoyingly sets META to Option (and of course resets the console map to US).
It should be:
ALT = optionL
ALTGR = optionR
Quoted 7 lines
by default in most PC maps and the default kernel maps I think. I'll have an updated console-tools package ready later today, which will do it right for most Macs:
ALT = optionL
ALTGR = commandL or commandR

Quoted 10 lines

I may disagree with a lot of people, but this does not seem right to me. On international keyboards you need Mode_switch for a lot of characters (as you'll certainly know ;-), which is usually bound to AltGr on PC-Hardware. Under MacOS, this is effected by Option-Key combinations, so for a fully MacOS-compatible keymap you need to have ALTGR bound to Option. Also I feel that the purpose of the Meta or ALT(L) on Unix is more similar to that of Cmd in MacOS, but that's rather my personal opinion. Of course, things do not become simpler by the fact that optionL and optionR are identical on most Mac keyboards. If it were possible to make Fn-Opt generate ALTGR (or vice-versa), this would add some flexibility.

The problem here is that newer Apple keyboards additionally label OptionL as ALT and 3rd party keyboards with an additional OptionR label it as ALTGR, which pretty much limits the correct choices :-(. Anyway, I'll put keymap .inc files into console-tools that let you easily change it (eg. option-left-as-alt.inc, command-leftright-as-altgr.inc, etc.).

Quoted 36 lines

Quoted 16 lines
Quoted 16 lines
                                              _
I have to correct the keycodes I gave for the ^ key:
_
^: 52, xkb keycode 60 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 characters: ""
_
Fn-^: 110, xkb keycode 118 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "
RET: 36, xkb keycode 44 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 characters: "
Fn-RET: 72, xkb keycode 84 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 characters: "
Quoted 6 lines
Quoted 6 lines
Both Opt and Fn-Opt are 58 (xkb 66).
(with 2.2.17pre9-benh1)
With 2.2.17pre10-benh1, syslog reports:
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34) pressed.
Jul 12 02:12:45 miranda kernel: Unhandled ADB key (scancode 0x34)
released.
Quoted 5 lines
Quoted 5 lines
     _
when ^ is pressed, and
Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e) pressed.
Jul 12 02:12:46 miranda kernel: Unhandled ADB key (scancode 0x6e)
released.
Quoted 7 lines
Quoted 2 lines
       _
for Fn-^.
Ah, that's good information, just one question, what does the _^ key do in MacOS? I mean what can I do with this key in MacOS? Is it a modifier? A prefix? does it print characters?

Quoted 6 lines

It does mostly, but not always, the same as the Return key on the main keyboard. For some applications, it behaves differently. In the Finder, e.g. hitting KP_Enter will let you edit the name of the selected file. I think under MacOS, there's no difference between Fn-Return and the dedicated _^ key on the PB keyboard, and the standard ADB keyboard only has one KP_Enter anyway.

OK, so you want:
_^ = KEY_KPENTER
Fn-_^ = KEY_KPENTER
Fn-RET = KEY_KPENTER

Or something different for Fn-_^?

Quoted 3 lines

I had another problem with the new input layer I forgot to mention:
Though I selected /dev/mouse (-> inputs/mice) as input device and imps2 as protocol, the mouse does not work in mol in the console mode.

Hmm, dunno about that, should be the same. Does it work if you kill gpm?

Franz.

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

Derek Homeier

author

2000-07-12 12:59 UTC #7 lore raw

Quoted 3 lines · Franz Sirl

Quoted 3 lines
I may disagree with a lot of people, but this does not seem right to me. On international keyboards you need Mode_switch for a lot of characters (as you'll certainly know ;-), which is usually bound to AltGr on

PC-Hardware.

Quoted 8 lines

Quoted 7 lines
Under MacOS, this is effected by Option-Key combinations, so for a fully MacOS-compatible keymap you need to have ALTGR bound to Option. Also I feel that the purpose of the Meta or ALT(L) on Unix is more similar to that of Cmd in MacOS, but that's rather my personal opinion. Of course, things do not become simpler by the fact that optionL and optionR are identical on most Mac keyboards. If it were possible to make Fn-Opt generate ALTGR (or vice-versa), this would add some flexibility.

Quoted 6 lines

The problem here is that newer Apple keyboards additionally label OptionL as ALT and 3rd party keyboards with an additional OptionR label it as ALTGR, which pretty much limits the correct choices :-(. Anyway, I'll put keymap .inc files into console-tools that let you easily change it (eg. option-left-as-alt.inc, command-leftright-as-altgr.inc, etc.).

I see. Which of these is equivalent to the old single Option key?

Quoted 11 lines

Quoted 10 lines
Quoted 4 lines
Ah, that's good information, just one question, what does the _^ key do in MacOS? I mean what can I do with this key in MacOS? Is it a modifier? A prefix? does it print characters?
It does mostly, but not always, the same as the Return key on the main keyboard. For some applications, it behaves differently. In the Finder, e.g. hitting KP_Enter will let you edit the name of the selected file. I think under MacOS, there's no difference between Fn-Return and the dedicated _^ key on the PB keyboard, and the standard ADB keyboard only has one KP_Enter anyway.

Quoted 7 lines

OK, so you want:
_^ = KEY_KPENTER
Fn-_^ = KEY_KPENTER
Fn-RET = KEY_KPENTER
Or something different for Fn-_^?

Personally, I'd like something different for both, so they could be independently bound to the mousebuttons. If one wanted to use it as KP_Enter, it could probably still be bound in the console and xkb keymaps? I've no idea for a name, though. I think with the older kernels it was just NoKey (and couldn't be bound to any Key Symbol, but to the mousebuttons). KEY_LINEFEED, perhaps?

Fn-RET = KEY_KPENTER
_^ = KEY_KPENTER
Fn-_^ = [something different]

would probably also be o.k., though.

Quoted 7 lines

Quoted 4 lines
I had another problem with the new input layer I forgot to mention:
Though I selected /dev/mouse (-> inputs/mice) as input device and imps2 as protocol, the mouse does not work in mol in the console mode.
Hmm, dunno about that, should be the same. Does it work if you kill gpm?

Haven't tried that. The console mode doesn't work at the moment anyway, because it tries to switch to 640x480 at the end of the startup, but I doubt that's related to the mouse problem (that appears much earlier, when the first extensions are loaded).

Thanks,
Derek

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

Franz Sirl

2000-07-12 23:29 UTC #8 lore raw

Quoted 8 lines · Derek Homeier

Quoted 5 lines · Franz Sirl
The problem here is that newer Apple keyboards additionally label OptionL as ALT and 3rd party keyboards with an additional OptionR label it as ALTGR, which pretty much limits the correct choices :-(. Anyway, I'll put keymap .inc files into console-tools that let you easily change it (eg. option-left-as-alt.inc, command-leftright-as-altgr.inc, etc.).
I see. Which of these is equivalent to the old single Option key?

optionL-as-alt + commandLR-as-altgr probably. It's in the new console-tools package I have on devel now.

Quoted 7 lines

Personally, I'd like something different for both, so they could be independently bound to the mousebuttons. If one wanted to use it as KP_Enter, it could probably still be bound in the console and xkb keymaps? I've no idea for a name, though. I think with the older kernels it was just NoKey (and couldn't be bound to any Key Symbol, but to the mousebuttons). KEY_LINEFEED, perhaps?

Quoted 5 lines

Fn-RET = KEY_KPENTER
_^ = KEY_KPENTER
Fn-_^ = [something different]
would probably also be o.k., though.

How about the appended patch?

Franz.

drivers/macintosh/mac_keyb.c +2 -2

@@ -260,10 +260,10 @@ unsigned char adb_to_linux_keycodes[128]
 	 30, 31, 32, 33, 35, 34, 44, 45, 46, 47, 86, 48, 16, 17, 18, 19,
 	 21, 20,  2,  3,  4,  5,  7,  6, 13, 10,  8, 12,  9, 11, 27, 24,
 	 22, 26, 23, 25, 28, 38, 36, 40, 37, 39, 43, 51, 53, 49, 50, 52,
-	 15, 57, 41, 14,  0,  1, 29,125, 42, 58, 56,105,106,108,103,  0,
+	 15, 57, 41, 14, 96,  1, 29,125, 42, 58, 56,105,106,108,103,  0,
 	  0, 83,  0, 55,  0, 78,  0, 69,  0,  0,  0, 98, 96,  0, 74,  0,
 	  0,117, 82, 79, 80, 81, 75, 76, 77, 71,  0, 72, 73,124, 89,  0,
-	 63, 64, 65, 61, 66, 67, 41, 87,112, 99,  0, 70,  0, 68,  0, 88,
+	 63, 64, 65, 61, 66, 67, 41, 87,112, 99,  0, 70,  0, 68,101, 88,
 	  0,119,110,102,104,111, 62,107, 60,109, 59, 54,100, 97,116,116
 };

Derek Homeier

author

2000-07-14 13:07 UTC #9 lore raw

Quoted 9 lines · Franz Sirl

Quoted 7 lines · Derek Homeier
Personally, I'd like something different for both, so they could be independently bound to the mousebuttons. If one wanted to use it as KP_Enter, it could probably still be bound in the console and xkb keymaps? I've no idea for a name, though. I think with the older kernels it was just NoKey (and couldn't be bound to any Key Symbol, but to the mousebuttons). KEY_LINEFEED, perhaps?

Quoted 8 lines

Quoted 5 lines
Fn-RET = KEY_KPENTER
_^ = KEY_KPENTER
Fn-_^ = [something different]
would probably also be o.k., though.
How about the appended patch?

Excellent! Fn-RET also emulates Mouse-3 now, but I probably wouldn't have any use for an additional generic KP_Enter anyway (hmm, I do use it, in emacs, but I could use up any number of keys in emacs ;). My adb_buttons kernel arg is working again like it is supposed to (I know it's deprecated now, maybe I'll replace it with

echo 101 > /proc/sys/dev/mac_hid/mouse_button2_keycode echo 96 > /proc/sys/dev/mac_hid/mouse_button3_keycode

in /etc/rc.d/rc.local or wherever).

Thanks,
Derek

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