From: Michel Lanners <hidden> Date: 2000-10-22 16:30:01
Hi all,
I finally found the time to upgrade to Franz Sirl's XF 4.0.1 rpms. I
hoped to solve some of my keyboard problems, but it got worse :-((
My setup:
- Apple Extended Keyboard II (dmesg shows handler 3:
ADB keyboard at 2, handler set to 3
Detected ADB keyboard, type ISO, swapping keys.)
- kernel 2.2.17pre20-ben3 (the source tarball from benh's site) (to get
the new input stuff, which is enabled)
- XF 4.0.1 rpms from Franz (XFree86-4.0.1-0.36a)
- XKB enabled (but I couldn't get a decent map loaded... went back to
xmodmap)
First question: does anybody have pointers or info about how to setup
XKB? I've looked around a fair bit, but found nothing of value. Nothing
that specifies how to change the layout without blindly relying on some
undocumented options...
Second, my Alt'ed or Shift-Alt'ed keys still don't work. Under Linux
keycodes, there is no difference whether Alt is pressed or not; the
resulting key is the same, and xev shows the same old keycode as without
Alt.
Under ADB keycodes, there is a reaction to Alt, but it seems to be to
_turn_off_ the highest bit in the resulting keysym. The keycode is
right, though....
Then, with ADB keycodes, the key left of '1' and the one right to
'Shift_L' are swapped vs. my previous setup. Is it now 'the right way'?
Could be, since the default US map I got with X was right... So I guess
those keys have been swapped in the 'old' code for ages.
Anybody got any help? Especially the the Alt problem is _really_
annoying, since I have many usefull keys on an Alt'ed binding (like @,
#, \ and |).
Thanks
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-10-22 18:45:30
Second, my Alt'ed or Shift-Alt'ed keys still don't work. Under Linux
keycodes, there is no difference whether Alt is pressed or not; the
resulting key is the same, and xev shows the same old keycode as without
Alt.
Yup, my old french keymaps broke with XF4.0.1 too. I hacked something
that more or less works by changine some of the modifier definitions.
I'll send you my keymap in a separate email once I have it at hand. I
can't say I understood XKB however ;)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Martin Costabel <hidden> Date: 2000-10-22 19:05:54
Hi Michel,
I can tell you what is working for me. I have been using Franz's XF4
RPMs for quite a while without major problems (some minor ones still
persist, but since the RPMs are 3 months old, I won't repeat them here).
I am not using, however, the "linux" keycodes. Only the ADB codes.
Michel Lanners wrote:
Hi all,
I finally found the time to upgrade to Franz Sirl's XF 4.0.1 rpms. I
hoped to solve some of my keyboard problems, but it got worse :-((
My setup:
- Apple Extended Keyboard II (dmesg shows handler 3:
ADB keyboard at 2, handler set to 3
Detected ADB keyboard, type ISO, swapping keys.)
I have the same keyboard, French (azerty) keys.
- kernel 2.2.17pre20-ben3 (the source tarball from benh's site) (to get
the new input stuff, which is enabled)
I mostly use 2.4.0-test kernels, but it works for 2.2.17+ in the same
way.
- XF 4.0.1 rpms from Franz (XFree86-4.0.1-0.36a)
- XKB enabled
Same here.
(but I couldn't get a decent map loaded... went back to
xmodmap)
I am using the same keymaps as I have for years with the "old" input
layer. The only problem are those 2 swapped keys "@#" vs "<>". In
/usr/lib/X11/xkb, I changed the following:
In keycodes/macintosh, besides the usual definition of keycode 18, the
following swap:
- <LMTA> = 66;
+ <LMTA> = 63;
- <LALT> = 63;
+ <LALT> = 66;
Otherwise, in keymap/macintosh:
- xkb_symbols { include "macintosh/us(extended)" };
+ xkb_symbols { include "macintosh/fr" };
The modifiers in symbols/macintosh/fr are defined as (and this is
exactly as I had it before in XF3.3.6)
key <LMTA> { [ Meta_L ] };
key <LFSH> { [ Shift_L ] };
key <LCTL> { [ Control_L ] };
key <LALT> { [ Mode_switch ] };
key <RMTA> { [ Meta_R ] };
key <RTSH> { [ Shift_R ] };
key <RCTL> { [ Control_R ] };
key <RALT> { [ Alt_R ] };
and
modifier_map Shift { Shift_L, Shift_R };
modifier_map Lock { Caps_Lock };
modifier_map Control{ Control_L, Control_R };
modifier_map Mod1 { Meta_L, Meta_R };
modifier_map Mod3 { Mode_switch };
In symbols.dir, there is an added line
+-------- -------- macintosh/fr(extended)
In XF86Config, I have
# Option "XkbDisable"
Option "XkbRules" "xfree86"
Option "XkbModel" "macintosh_old"
Option "XkbLayout" "fr"
Option "XkbCompat" ""
With this, everything works. At startx, I get a warning in the console:
(II) Using deprecated Macintosh keycodes.
The XKEYBOARD keymap compiler (xkbcomp) reports:
Error: Meta_R added to symbol map for multiple modifiers
Using Mod1, ignoring Mod4.
Error: Meta_L added to symbol map for multiple modifiers
Using Mod1, ignoring Mod4.
Errors from xkbcomp are not fatal to the X server
I did not try to fix this, because it ain't broken.
First question: does anybody have pointers or info about how to setup
XKB? I've looked around a fair bit, but found nothing of value. Nothing
that specifies how to change the layout without blindly relying on some
undocumented options...
Second, my Alt'ed or Shift-Alt'ed keys still don't work. Under Linux
keycodes, there is no difference whether Alt is pressed or not; the
resulting key is the same, and xev shows the same old keycode as without
Alt.
Under ADB keycodes, there is a reaction to Alt, but it seems to be to
_turn_off_ the highest bit in the resulting keysym. The keycode is
right, though....
Then, with ADB keycodes, the key left of '1' and the one right to
'Shift_L' are swapped vs. my previous setup. Is it now 'the right way'?
Could be, since the default US map I got with X was right... So I guess
those keys have been swapped in the 'old' code for ages.
Looks to me like an arbitrary decision. But since it is Franz and Ben
who have decided that the kernels and maps that we have used for years
were wrong, we will have to accept this decision.
Anybody got any help? Especially the the Alt problem is _really_
annoying, since I have many usefull keys on an Alt'ed binding (like @,
#, \ and |).
From: Benjamin Herrenschmidt <hidden> Date: 2000-10-22 20:53:01
quoted
Then, with ADB keycodes, the key left of '1' and the one right to
'Shift_L' are swapped vs. my previous setup. Is it now 'the right way'?
Could be, since the default US map I got with X was right... So I guess
those keys have been swapped in the 'old' code for ages.
Looks to me like an arbitrary decision. But since it is Franz and Ben
who have decided that the kernels and maps that we have used for years
were wrong, we will have to accept this decision.
That's not that we decided our keymaps were wrong (well, they had a few
things wrong). No, the major issue is to have keycode consistency among
various archs and various PPC machines. There's no reason why the same
USB keyboard would give different keycodes depending if your machine is
considered as a pmac or not.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Martin Costabel <hidden> Date: 2000-10-22 22:13:20
Benjamin Herrenschmidt wrote:
That's not that we decided our keymaps were wrong (well, they had a few
things wrong). No, the major issue is to have keycode consistency among
various archs and various PPC machines. There's no reason why the same
USB keyboard would give different keycodes depending if your machine is
considered as a pmac or not.
OK, this argument is relevant for the case of "linux" keycodes, where
the same keymaps are now supposedly used on PCs and on Pmacs.
For the case of ADB keycodes, this argument is empty. Or are there other
machines than Pmacs that now use the mac_keycodes[] translation table
and macintosh keymaps and that didn't use macintosh keymaps before? It
is in this case that the backwards compatibility problem appears. For
the "old" input layer, one needed different keymaps for ADB and USB
keyboards (differing by swapping those 2 keys).
Now with the new input layer one needs the same keymap, and the decision
is whether this is the old ADB keymap or the old USB keymap. Right now,
it is the old USB keymap. If I understand this correctly, it suffices to
swap the numbers "10" and "50" in the mac_keycodes[] table in
drivers/input/keybdev.c to obtain compatibility with the old ADB
keymaps. Or maybe one additionally needs to swap the positions 10 and 50
(the numbers "41" and "86") in adb_to_linux_keycodes[] in
drivers/macintosh/adbhid.c? I am too tired now to understand this.
Anyway, there are more important problems to solve :-)
--
Martin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-10-23 12:32:46
OK, this argument is relevant for the case of "linux" keycodes, where
the same keymaps are now supposedly used on PCs and on Pmacs.
For the case of ADB keycodes, this argument is empty. Or are there other
machines than Pmacs that now use the mac_keycodes[] translation table
and macintosh keymaps and that didn't use macintosh keymaps before? It
is in this case that the backwards compatibility problem appears. For
the "old" input layer, one needed different keymaps for ADB and USB
keyboards (differing by swapping those 2 keys).
That's more complicated. Some ADB keyboard have the same layout as
equivalent PC keyboard. Some have not. (Depending on the country). The
"swapping" of the corner key depends on ISO vs. ANSI keyboard and is now
handled by the driver, so an identical keymap should be used in both cases.
With the Linux keycodes, a "standard" keymap should work for any USB
keyboard or any ADB keyboard with a "standard" layout. For those having a
specific "Apple" layout, you still need a specific keymap (like French),
but one single keymap should now handle all cases for the "corner" key.
Now with the new input layer one needs the same keymap, and the decision
is whether this is the old ADB keymap or the old USB keymap. Right now,
it is the old USB keymap. If I understand this correctly, it suffices to
swap the numbers "10" and "50" in the mac_keycodes[] table in
drivers/input/keybdev.c to obtain compatibility with the old ADB
keymaps. Or maybe one additionally needs to swap the positions 10 and 50
(the numbers "41" and "86") in adb_to_linux_keycodes[] in
drivers/macintosh/adbhid.c? I am too tired now to understand this.
The linux keycodes are completely different keycodes. (based on PS/2
keycodes currently). The "old" keycodes are ADB keycodes as they used to
be. When enabling ADB keycodes, both ADB and USB keycodes are converted
to Linux keycodes and then back to ADB keycodes with the abdhid.c. That's
a bit hackish, but it ensures consistency, and we expect everybody to
switch to linux keycodes over time.
Anyway, there are more important problems to solve :-)
From: Michel Lanners <hidden> Date: 2000-10-29 16:47:10
Hi all,
On 22 Oct, this message from Martin Costabel echoed through cyberspace:
I can tell you what is working for me. I have been using Franz's XF4
RPMs for quite a while without major problems (some minor ones still
persist, but since the RPMs are 3 months old, I won't repeat them here).
I am not using, however, the "linux" keycodes. Only the ADB codes.
I went back now to ADB kezcodes as well, since MOL doesn't seem to work
with Linux keycodes.
I am using the same keymaps as I have for years with the "old" input
layer.
And which ones are those? Where did you get them from?
The only problem are those 2 swapped keys "@#" vs "<>".
For the record, with ADB keycodes, all keys are OK in MOL _except_ those
two swapped keys. I wonder whether swapping them is such a good idea...
In keycodes/macintosh, besides the usual definition of keycode 18, the
^^^^^^^^^^
Which one is this?
Otherwise, in keymap/macintosh:
- xkb_symbols { include "macintosh/us(extended)" };
+ xkb_symbols { include "macintosh/fr" };
I have no macintosh/fr file. Where did you get yours from?
In XF86Config, I have
# Option "XkbDisable"
Option "XkbRules" "xfree86"
Option "XkbModel" "macintosh_old"
Option "XkbLayout" "fr"
Option "XkbCompat" ""
I still don't see how those Xkb options relate to anything in the files
below /usr/lib/X11/xkb. Anybody can explain this?
Thanks
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Martin Costabel <hidden> Date: 2000-10-29 18:57:32
Michel Lanners wrote:
Hi all,
On 22 Oct, this message from Martin Costabel echoed through cyberspace:
quoted
I am using the same keymaps as I have for years with the "old" input
layer.
And which ones are those? Where did you get them from?
It's been so long, I don't remember where I got mine from originally,
but at the following 2 addresses you should find all you need: Etienne
Herlent maintains the FAQ of news://fr.comp.os.unix.mac and some related
material, see
http://perso.easynet.fr/~eherlent/linuxmac.html, and there are infos in
http://www.linux-france.org/article/materiel/mac/
They even have put all necessary changes and files into an RPM.
quoted
The only problem are those 2 swapped keys "@#" vs "<>".
For the record, with ADB keycodes, all keys are OK in MOL _except_ those
two swapped keys. I wonder whether swapping them is such a good idea...
quoted
In keycodes/macintosh, besides the usual definition of keycode 18, the
^^^^^^^^^^
Which one is this?
This is (or used to be) the key to the left of "1", above TAB.
quoted
Otherwise, in keymap/macintosh:
- xkb_symbols { include "macintosh/us(extended)" };
+ xkb_symbols { include "macintosh/fr" };
I have no macintosh/fr file. Where did you get yours from?
quoted
In XF86Config, I have
# Option "XkbDisable"
Option "XkbRules" "xfree86"
Option "XkbModel" "macintosh_old"
Option "XkbLayout" "fr"
Option "XkbCompat" ""
I still don't see how those Xkb options relate to anything in the files
below /usr/lib/X11/xkb. Anybody can explain this?
I can't explain, I just use it and it works.
Anyway, with the new LinuxPPC distribution that is leaving its egg right
now, we shall all soon be converted to linux keycodes, I guss :-)
--
Martin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi all,
On 22 Oct, this message from Martin Costabel echoed through cyberspace:
quoted
I can tell you what is working for me. I have been using Franz's XF4
RPMs for quite a while without major problems (some minor ones still
persist, but since the RPMs are 3 months old, I won't repeat them here).
I am not using, however, the "linux" keycodes. Only the ADB codes.
You have attached my answer to the problem we seem to have in France
regarding the new input layer, since no good azerty keymap exists in the
standard distrib.
- fr-mac.kmap.gz: a map to use at console (place in
/usr/lib/kbd/keymaps/mac/ and run kbdconfig)
- xf86_nil_fr.diff.gz: a diff to stuff I modified in the xkb directory. (do
not try to apply it, but inspect it and see what should be included in the
distribution, test it)
Basically both are last Marc Shapiros's production, with various enhancements
(not much...) and with keycodes # completely redesigned regarding the new
input layer.
Note: you'd _rather_ use linux keycodes if you setup this...
I have only one problem so far: I can't switch from X to console. Otherwise
it's very neat.
I still don't see how those Xkb options relate to anything in the files
below /usr/lib/X11/xkb. Anybody can explain this?
I've yet to find some doc about it, but starting to play with rules/xfree86
made me learn what you can see in xf86_nil_fr.
Last but not least:
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
# Option "XkbDisable"
Option "XkbRules" "xfree86"
Option "XkbModel" "macintosh"
Option "XkbLayout" "fr"
EndSection
All using XFree86-4.0.1-0.36a and happy (so faster with r128).
And an advice: if you plan to move from XFree 4.0 to 4.0.1, have a clean
linuxppc install not far (other partition) to recover things once your
keyboard is completely screwed...
Later,
--
GoM
From: Michel Lanners <hidden> Date: 2000-10-29 21:59:00
Hi Guillaume,
On 29 Oct, this message from Guillaume Laures echoed through cyberspace:
- fr-mac.kmap.gz: a map to use at console (place in
/usr/lib/kbd/keymaps/mac/ and run kbdconfig)
I'll have a look, but as long as I stay in ADB keycodes, my console
works ok. I have yet to check why this is so ;-)
- xf86_nil_fr.diff.gz: a diff to stuff I modified in the xkb directory. (do
not try to apply it, but inspect it and see what should be included in the
distribution, test it)
I'll have a look, thanks.
Basically both are last Marc Shapiros's production, with various enhancements
(not much...) and with keycodes # completely redesigned regarding the new
input layer.
Note: you'd _rather_ use linux keycodes if you setup this...
Any solution for MOL? It doesn't work for me with Linux keycodes...
quoted
I still don't see how those Xkb options relate to anything in the files
below /usr/lib/X11/xkb. Anybody can explain this?
I've yet to find some doc about it, but starting to play with rules/xfree86
made me learn what you can see in xf86_nil_fr.
That's the way I'm going as well: just reverse engineer the stuff.
Change somthing and see what happens ;-) So far I've successfully made X
load some XKB stuff, but the result is totally messed up keys. Maybe
some old xmodmap setting is getting in my way...
And an advice: if you plan to move from XFree 4.0 to 4.0.1, have a clean
linuxppc install not far (other partition) to recover things once your
keyboard is completely screwed...
Hehehehe.... For this sort of thing, I always first make backups of
config files (my xdm directory has been deleted only once by an RPM
install...), then I keep the old RPMs handy, and then I have a second
machine to telnet into the DUU (Device Under Upgrade ;-).
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-10-29 22:04:49
Salut Martin,
On 29 Oct, this message from Martin Costabel echoed through cyberspace:
It's been so long, I don't remember where I got mine from originally,
Hehe... don't ask me neither where all my nice working configs are
coming from. That's the real upgrade nightmare: let's see which nicely
crafted working config gets hosed this time....
OK, I'll have a look. One place I have looked into is the
Francophones-HOWTO.
quoted
quoted
The only problem are those 2 swapped keys "@#" vs "<>".
For the record, with ADB keycodes, all keys are OK in MOL _except_ those
two swapped keys. I wonder whether swapping them is such a good idea...
quoted
In keycodes/macintosh, besides the usual definition of keycode 18, the
^^^^^^^^^^
Which one is this?
This is (or used to be) the key to the left of "1", above TAB.
Found it. For me, however, it is the key between left shift and 'y'.
That's probably due to the swap with the other key. Note that standard
XFree XKB maps don't contain that key between left shift and the first
letter. So the swapped position may be right after all....
quoted
I still don't see how those Xkb options relate to anything in the files
below /usr/lib/X11/xkb. Anybody can explain this?
I can't explain, I just use it and it works.
;-))
Anyway, with the new LinuxPPC distribution that is leaving its egg right
now, we shall all soon be converted to linux keycodes, I guss :-)
Unfortunately they're sitting in the US, so we can only hope that
international keyboards will be supported...
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-10-29 22:09:02
Hi all,
Just to add to this thread, I wonder whether anybody has noticed that
Apple Extended keyboards don't get switched to a different ADB handler,
in order to enable right and left modifier keys to send different
keycodes.
Doesn't anybody need this anymore? Wouldn't it be nice to do that
anyway, so that left and right keys _can_ be used differently if needed?
I can't remember when this functionality disappeared, but it might be a
long time ago ;-) It might even have been in the old MkLinux DR2.1
install I originally started with...
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi Guillaume,
On 29 Oct, this message from Guillaume Laures echoed through cyberspace:
quoted
- fr-mac.kmap.gz: a map to use at console (place in
/usr/lib/kbd/keymaps/mac/ and run kbdconfig)
I'll have a look, but as long as I stay in ADB keycodes, my console
works ok. I have yet to check why this is so ;-)
Installed initscripts-5.35-1a ?
It will switch you to linux keycodes in conole, I guess by sending a 1 in the
appropriate location in /proc
quoted
Basically both are last Marc Shapiros's production, with various enhancements
(not much...) and with keycodes # completely redesigned regarding the new
input layer.
Note: you'd _rather_ use linux keycodes if you setup this...
Any solution for MOL? It doesn't work for me with Linux keycodes...
I didn't used mol for a while, have enough to do in the linux side...
That's the way I'm going as well: just reverse engineer the stuff.
Change somthing and see what happens ;-) So far I've successfully made X
load some XKB stuff, but the result is totally messed up keys. Maybe
some old xmodmap setting is getting in my way...
XKBModel = macintosh_old may be useful to you...
quoted
And an advice: if you plan to move from XFree 4.0 to 4.0.1, have a clean
linuxppc install not far (other partition) to recover things once your
keyboard is completely screwed...
Hehehehe.... For this sort of thing, I always first make backups of
config files (my xdm directory has been deleted only once by an RPM
install...), then I keep the old RPMs handy, and then I have a second
machine to telnet into the DUU (Device Under Upgrade ;-).
I made regularly a complete .tbz of all my stuff, since upgrading a rpm may be
easy & messy, but downgrading is really a pain.
--
GoM
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi all,
Just to add to this thread, I wonder whether anybody has noticed that
Apple Extended keyboards don't get switched to a different ADB
handler,
in order to enable right and left modifier keys to send different
keycodes.
Hopefully they are back wtih the linux keycodes.
I mapped R & L ctrl to Control.
L alt to Mode_switch (the key we use in MacOS to modify the meaning of
keys, eg l-> |).
R & L Apple to meta
R alt to "I dunno what" but this is the key that allows to switch from X
to console (with alt + Fx), needs to be fixed to Mode_switch as well,
and use both Apple to switch from X to console
--
GoM
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-11-02 07:12:55
Hi all,
My keyboard finally works again as expected, so I figured I'd tell the
list so my research work ends up in the archives ;-)
My setup is still the same basically:
quoted
My setup:
- Apple Extended Keyboard II (dmesg shows handler 3:
ADB keyboard at 2, handler set to 3
Detected ADB keyboard, type ISO, swapping keys.)
- a recent 2.2 kernel (to get the new input stuff, which is enabled)
quoted
- XF 4.0.1 rpms from Franz (XFree86-4.0.1-0.36a)
- XKB enabled
What I'm saying below works only with ADB keycodes. As far as I can
tell, with Linux keycodes, only the 'keycodes' part of the XKB config
needs to be changed.
Why not use Linux keycodes? Because MOL doesn't work with them.
First, a few words about how XKB works.
XKB defines a way to handle keyboards under X, via a definition of all
aspects of a keyboard (this goes as far as specifying the physical
appearance, so an image of the keyboard can be printed). Everything
related to XKB can be found below /usr/X11R6/lib/X11/xkb.
A complete keyboard definition is called a keymap, and contains a few
different components. Have a look at keymap/macintosh, as distributed
with XF4:
// $XConsortium: macintosh /main/11 1996/03/07 13:42:13 kaleb $
// $XFree86: xc/programs/xkbcomp/keymap/macintosh,v 1.1 1999/05/23 05:27:51 dawes Exp $
default xkb_keymap "macintosh" {
xkb_keycodes { include "macintosh" };
xkb_types { include "default" };
xkb_compatibility { include "default" };
xkb_symbols { include "macintosh/us(extended)" };
xkb_geometry { include "macintosh" };
};
So a keymap has these five components. The keycodes tell what numeric
code the keyboard (& driver) send back on a specific keypress. The
reference is the geographical location of the keys on the keyboard. Some
keys have names (like <ESC>, <TAB>), others coordinates like <AE01>
(first alpha key in the top (5th = 'E') row, etc.
Since we're using ADB keycodes, and XF4 uses Linux keycodes by default,
the keycode part needs to be specified. I started with
keycodes/macintosh, but made these changes:
In keycodes/macintosh, besides the usual definition of keycode 18, the
following swap:
That's because ALT and META are swapped, and the key between left shift
and 'y' (or 'z') is missing.
Otherwise, in keymap/macintosh:
- xkb_symbols { include "macintosh/us(extended)" };
+ xkb_symbols { include "macintosh/fr" };
Now, this is the symbols part of the map, which defines what letter,
number or other symbol a specific key sends back, depending on the
modifier keys that are depressed.
The symbols/macintosh/us file is standard XF4; the fr part is not.
Therefore I used the us part, but with the following changes to get the
modifier keys to work as expected:
Now, since I don't have a us keyboard, but rather Swiss-French, I
changed the 'wrong' keys with xmodmap (since I always had that part
working ok). However, there is no problem (and that's the better way),
to add these changes in symbols/macintosh as well, maybe by adding a
separate file. Keep in mind however, that that file needs to be added to
symbols.dir.
Now, for XF86config:
For some reason, specifying the complete macintosh keymap didn't work.
Therefore, I specified the components I needed to change (keycodes and
symbols):
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbModel" "macintosh_old"
Option "XkbKeycodes" "macintosh"
Option "XkbSymbols" "macintosh/us(extended)"
EndSection
As you can see, the five components in the keymap/macintosh file have
their equivalent XFree options. Remember that "XkbModel" "macintosh_old"
selects ADB keycodes; but I don't know what that exactly means for XF4.
Anybody care to comment?
With this in place, everything works as expected, with these exceptions:
- the us symbols are active while not logged in, that is in xdm's login
screen. The solution is to modify the symbols/macintosh/us part,
instead of relying on xmodmap.
- the 'Apple' key doesn't work for switching back to console. I'll hunt
that down ASAP.
Have fun
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/