Keycodes for the new input layer

Keycodes for the new input layer

[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,
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/

Re: Keycodes for the new input layer

[Franz Sirl]

On Tue, 11 Jul 2000, Derek Homeier wrote:
> 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?

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/

Re: Keycodes for the new input layer

[Derek Homeier]

On Tue, 11 Jul 2000, Franz Sirl wrote:

> On Tue, 11 Jul 2000, Derek Homeier wrote:
> > 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?
>
> 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/

Re: Keycodes for the new input layer

[Franz Sirl]

At 12:41 12.07.00, Derek Homeier wrote:
>On Tue, 11 Jul 2000, Franz Sirl wrote:
>
> > On Tue, 11 Jul 2000, Derek Homeier wrote:
> > > 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?
> >
> > 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).

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


>                                               _
>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-^.

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/

Re: Keycodes for the new input layer

[Derek Homeier]

On Wed, 12 Jul 2000, Franz Sirl wrote:

> At 12:41 12.07.00, Derek Homeier wrote:
> >On Tue, 11 Jul 2000, Franz Sirl wrote:
> >
> > > On Tue, 11 Jul 2000, Derek Homeier wrote:
[snip]
> > >
> >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
>
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.
>
> >                                               _
> >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-^.
>
> 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/

Re: Keycodes for the new input layer

[Franz Sirl]

At 13:49 12.07.00, Derek Homeier wrote:
>On Wed, 12 Jul 2000, Franz Sirl wrote:
>
> > At 12:41 12.07.00, Derek Homeier wrote:
> > >On Tue, 11 Jul 2000, Franz Sirl wrote:
> > >
> > > > On Tue, 11 Jul 2000, Derek Homeier wrote:
>[snip]
> > > >
> > >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
> >
>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.).

> >
> > >                                               _
> > >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-^.
> >
> > 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.

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

Or something different for Fn-_^?


>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/

Re: Keycodes for the new input layer

[Derek Homeier]

On Wed, 12 Jul 2000, Franz Sirl wrote:

> >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.).
>
I see. Which of these is equivalent to the old single Option key?

> > > 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.
>
> 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.
>
> >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/

Re: Keycodes for the new input layer

[Franz Sirl]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

On Wed, 12 Jul 2000, Derek Homeier wrote:
> On Wed, 12 Jul 2000, Franz Sirl wrote:
> > 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.

> 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.

How about the appended patch?

Franz.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: kbd6-ben1-9.patch --]
[-- Type: text/x-c; name="kbd6-ben1-9.patch", Size: 890 bytes --]

--- linux-pmac-benh/drivers/macintosh/mac_keyb.c	Thu Jul 13 00:23:37 2000
+++ linux-pmac-benh-fra/drivers/macintosh/mac_keyb.c	Thu Jul 13 01:18:21 2000
@@ -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
 };
 

Re: Keycodes for the new input layer

[Derek Homeier]

On Thu, 13 Jul 2000, Franz Sirl wrote:

> On Wed, 12 Jul 2000, Derek Homeier wrote:
>
> > 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.
>
> 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/