# eeprom keyboard-layout=Japanese
# eeprom keyboard-layout=US-English
/boot/solaris/bootenv.rc
, and look for the line that says setprop keyboard-layout 'Japanese'
Both architectures can also set the keyboard under
LAYOUT=
in /etc/defaults/kbd
, but AFAICT
the correct place to set them is as above.
The choices for keyboard layouts are listed by the kbd
-s
tool.
There seem to be some layouts defined for feeding this
kbd -s
in
/usr/share/lib/keytables/type_6/kbd_layout
, but I am
not sure how this works exactly.
First, keyboards have Types and Layouts---both are numbers.
I believe the Type of a keyboard is a consequence of its connection to the computer, and the Layout is a knob you must twist in the operating system to match the physical layout and labeling of the key caps. Sun also named their SPARC keyboards Type 3, Type 4, Type 5, Type 6, but this does not match the kernel's idea of Type exactly: Type 6 is any USB keyboard, whether it's the Sun Type 6 keyboard, or a PeeCee or Mac keyboard. Type 101 is any PS/2 keyboard, even if it has 104, 105, 106 keys. Type 4 is any SPARC serial keyboard, even if the label on the bottom of the keyboard says confusingly ``Type 5''. or, I bet, ``Type 3''.
kbd -l
on very new (post-Solaris 10) versions of
Solaris will query /dev/kbd and tell you the Type number of your
keyboard. Although the kernel retains some idea of keyboard
Layout number, only the keyboard Type number the kernel returns is
fundamental. The Layout code returned by the kernel is sort of
like the tty driver remembering the number of rows and columns of
the attached terminal---you tell the kernel, and the kernel
remembers it for you in lieu of direct communication between bits
of userland through something like /var/run/utmp. (in this case,
the communication it facilitates is between the console keyboard
type setting, and the X server, which has completely different
keytables which are matched up by Type and Layout numbers.)
Second, the Layout of a keyboard is chooseable, and kbd -l
will tell you your current choice. kbd -s
also has the
ability to load layouts by type number and layout number from
/usr/share/lib/keytables/type_mm/layout_nn
where
mm
is the type number in decimal, and nn
is the layout number in hex. The layout_nn
files are
hard-linked to mnemonic language names that kbd -s
does
not use. The layout names are used in several places---used by
OpenPROM, bootvar.rc
, and
/etc/default/kbd
---and they are the ones displayed in
kbd -s
, not the hardlinks.
There is a file in
/usr/share/lib/keytables/type_6/kbd_layouts
which
seems to map from kbd -s
language names to layout
numbers (in decimal!). The issue of namespace is a tricky one
here. Somehow, I should be able to ask for the layout
``US-English'' and get something reasonable whether I plug in a
PS/2 keyboard or a USB keyboard, so in a sense we can meaningfully
have the same Layout for two different Types. Does Solaris
include this idea, or are the layout names different for each
Type?
The only layout number shared between Type 101 and Type 6 is 0x23,
and that Layout is for 'TurkishF/turkeyf' for USB/type6 and
'???/france' for PS2/type101. so, there are separate per-Type
numberspaces for Layout numbers because one number is shared but
has different meaning on each. Is it then the kbd -s
name like US-English or Japanese which can stay the same, but map
to different layout codes depending on the keyboard interface Type
I feed it? If I had a PS/2 keyboard, would another kbd_layouts
file magically appear in the type_101 directory? How?! Or would
kbd -s
just quit working with a PS/2 keyboard? Or
kbd -s
output is hard-coded into kbd
,
and yet another copy of the information is put into kbd_layouts to
confuse people, like the layout_xx hardlinks to language names
that nothing uses---but if that's the case, why does
ls -lu
show kbd
reading the
kbd_layouts
file? no idea. x4.
Finally, the keymap layout actually used by the kernel is the one
shown by dumpkeys
. There are a lot more key
definitions in dumpkeys
output than in the layout
files. According to dumpkeys(4)
, there is some
secret master layout file, one for each keyboard Type code, stored
inside the kernel.
This whole thing could be worse---it could be XKB---but it could certainly be better.
Anyway, first use:
$ dumpkeys | grep "base '\\\\b'"
to find the key number of your backspace key. Then, use kbd
-l
and the dialog above to find the layout file your
keyboard is using (/usr/share/lib/keytables/type_mm/layout_nn
where
mm
is the type number in decimal, and nn
is the layout number in hex), and add this line to the end of the layout
file, but alter the incantation by replacing key 42
with the key number of your
backspace key:
# vt220
key 42 base '\177' shift '\177' caps '\177' ctrl '\b' altg nop
and then rechoose your keyboard type with kbd -s
.
This will fix your backspace key on the console. Fortunately (?)
the stty erase
defaults for the Solaris console are
already set to ^?, mismatching the console Solaris actually
delivers. so, there's no need to fix the console tty
configuration. phew.
xterm
. I use CDE. I dislike it. I find it crass
and ugly. but I've no patience for that bloated mediocre crashing
GNOME garbage, none. You probably use GNOME and may need
to find a different way to do this. Please write me. The fix for
CDE is to edit
/usr/dt/config/${LANG%.*}/sys.resources
and
/usr/dt/config/C/sys.resources
where
${LANG%.*}
is the string returned by typing
echo ${LANG%.*}
at a Bourne shell prompt, changing
the following line:
*ttyModes: erase ^H
to:
*ttyModes: erase ^?
This will make the pty's allocated by xterm have delete set as
their erase
special character. There was no
analagous step on the console, because console tty's already have
erase ^?, yes, mismatching the console keyboard as-shipped.
/usr/openwin/lib/locale/${LANG}/app-defaults/XTerm
and /usr/openwin/lib/app-defaults/XTerm
. Have a look
at the *VT100.Translations
property. This is made up
of something like subproperties separated by embedded newlines.
Add a key definition to this property:
which will have almost the same effect as
*VT100.backarrowKey: False
on a modern xterm build,
because this resource seems to be missing from Solaris xterm. I'm
not sure what's the right thing to do with shift-, meta-, or
control-BackSpace, but this line accomplishes the same thing as
the mucking around with keytables did on the console. Obviously
when finished you need to preserve the fact that all lines end
with \n\
except the last one which ends with
\n
It may need to be fixed in more places. I remember I had to fix
it in the termcap file in FreeBSD for some reason, but forget what
that reason was. tset
maybe?
Edit
/usr/openwin/lib/locale/${LANG}/app-defaults/XTerm
and /usr/openwin/lib/app-defaults/XTerm
. Add:
*VT100.eightBitInput: False
to make the Meta key work in emacs. In a UTF8 locale, you can
C-x RET k utf-8
, C-x RET t utf-8
, and
emacs will mostly work with some of the more exotic keys and
characters I think, though I've not tested it well because I
haven't found a Unicode font I can tolerate so I can test
doublewide characters. On a PeeCee keyboard, the Logo key is
Meta, the Menu key is Compose, and the Alt key is not the same as
Meta.
Then, have a look at the *VT100.Translations
property. This is made up of something like subproperties
separated by embedded newlines. Now, remove from this
*VT100.Translations
resource all the muck you don't
like, such as:
You might want to leave alone the part where they fix the numeric keypad which is kind of nice.
The X server has a separate keytable similar to the
/usr/share/lib/keytables
keytable. It doesn't
use the console keymap loaded into the kernel at all, but it
retrieves the Type and Layout codes loaded into the kernel,
and uses these as a lookup key in
/usr/openwin/share/etc/keytables/keytable.map
to
find the filename in which the layout is stored. The X server
layouts are a little more advanced than the console layouts in
that they can handle locking keys and non-repeating keys, and
also they map keys to symbols, not to terminal input. The
mapping of X keys to terminal input or editor text is, I
think, now an Xlib function not an X server function, though
this may have changed at some time in the past---I'm not sure
how it works exactly. Not understanding it fully is kind of a
problem, but at least we can swap CapsLock and Control. Here
are some Sun bug ID's that kind of suggest where the mapping
from keypresses to text might be happening, at least for
non-Asian languages:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6303238
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6280195
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6280154
According to a random note I found on the web, the X server is
usually unable to determine a layout for ``non-Sun''
keyboards, so it chooses Layout 0. I doubt this is really
true. I would expect it to choose whatever layout is set by
kbd
based on OpenPROM,
/boot/solaris/bootenv.rc
, or
/etc/default/kbd
. Here is another random web
note that might be useful some day:
To use an USB keyboard and/or mouse with a SPARC system that does
not have USB support in the bootprom, you have to setup two
variables in /etc/system, telling the system the physical device
path for the USB keyboard and/or mouse, like this:
set consconfig:usb_kb_path="/pci@1f,4000/pci@4/pci9710,35@6,1/keyboard@5"
set consconfig:usb_ms_path="/pci@1f,4000/pci@4/pci9710,35@6/mouse@4"
http://www.sun.com/desktop/whitepaper/Dual_FW_Whitepaper.pdf
That looks to me rather unhopeful because it's the nature of USB keyboards to move around and not have exact device paths. They need something like a volume manager daemon to associate them with consoles. Often there is more than one of them---just the fact you can't specify multiple mice suggests this syntax is controlling an inadequate jury-rigged input system.
In my case, I had a Type 5c keyboard, the non-Unix variant
with Control in the wrong spot. It was automatically
identifying itself in kbd -l
as Type 4, Layout 33
(I had not used the kbd -s
tool or OpenPROM
variables). If you have old Solaris, you won't have the
-l
option of kbd
, so you can either
guess, or try to figure out which keytable Xsun is reading
using ls -lut
. Anyway, after figuring out Type 4
Layout 33, keytable.map
told me that, for this
Type and Layout, I should edit
/usr/openwin/share/etc/keytables/US5.kt
(no
layout numbers in hex this time, always nice), which I changed
as follows:
--- US5.kt.orig Tue Apr 3 17:24:10 2007
+++ US5.kt Tue Apr 3 17:31:25 2007
@@ -76,8 +76,8 @@
# modifier_group_identifier scancode scancode ...
#
shift 99 110 # Left Shift, Right Shift
-lock 119 # CapsLock
-control 76 # Control
+lock 76 # CapsLock
+control 119 # Control
mod1 120 122 # Left Meta, Right Meta
mod2 13 # Altgraph
mod3 98 # NumLock
@@ -237,7 +237,7 @@
49 NN XK_L5 XK_L5 SunXK_Front
51 NN XK_L6 XK_L6 SunXK_Copy
-119 NP XK_Caps_Lock
+119 NN XK_Control_L
77 RN XK_A
78 RN XK_S
79 RN XK_D
@@ -291,7 +291,7 @@
95 NN XK_L9 XK_L9 SunXK_Find
97 NN XK_L10 XK_L10 SunXK_Cut
-76 NN XK_Control_L
+76 NP XK_Caps_Lock
19 NN XK_Alt_L
120 NN XK_Meta_L
121 RN XK_space
Xorg uses the XKB extension which is utterly full of black
magic to me, although there are some pointers to documentation
in the README files in /usr/X11/lib/X11/xkb
that
might be a good place to start reading.
In short, there is already canned support inside XKB to swap your control and capslock key in some macro- or script-driven way. You just have to ask for it.
The first thing to do is make an xorg.conf. Log out of your X
session, and from the dtlogin window ask for a Console login.
Login to the console as root, and run Xorg
-configure
which will create a file named xorg.conf.new
which holds (parts of) Xorg's autoconfigured settings,
intended to let you twist the most commonly wanted knobs.
Then, test that Xorg did what it's designers intended it to
correctly (maybe asking a lot) by running
Xorg -config ./xorg.conf.new
and make sure it
takes control of the monitor, and that you can move the mouse
pointer around. If it works, quit the Xorg server by pressing
Control-Alt-BackSpace.
If the above test works, it should be safe to install the
xorg.conf.new
you just made in
/etc/X11/xorg.conf
. Then, edit it as
follows:
--- xorg.conf.orig Wed Apr 2 14:21:38 2008
+++ xorg.conf Wed Apr 2 14:21:20 2008
@@ -33,6 +33,7 @@
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
+ Option "XkbOptions" "ctrl:swapcaps"
EndSection
Section "InputDevice"
I'm sure you won't make any mistakes, so don't bother testing
it by typing Xorg
, just log out of the shell and
let dtlogin start it for you.
I have not been able to fix Control/CapsLock on the console. It's obvious how one might edit the keytables, but when I do this I end up with a control key that's stuck down. It doesn't function as control-lock---it just gets stuck down.
iiim-properties
at a prompt---that's the configurator
for the, whatever it is, which is doing this grab, and he'll
happily do whatever you like. There ought to be an emacs-friendly
grab for language switching if this is supposed to be a
developer-friendly platform, but at least there's a fast fix, and
the fix involves something useful, not a bunch of hopelessly
arcane and redundant garbage.