Please do a fresh installation of Red Hat Linux 9 and report back if
this problem persists.  If so, attach your X config file, and log file
to the bug report individually.  Also provide info as to wether you are
using GNOME or KDE, and a specific application or applications with which
this is reproduceable.  Also please provide the value of the LANG environment
variable.

I have just typed "12345" with the following scenarios:

1) CAPSLOCK=off SHIFT=off and I get "12345"
2) CAPSLOCK=on SHIFT=off and I get "12345"
3) CAPSLOCK=off SHIFT=on and I get "!@#$%"
4) CAPSLOCK=on SHIFT=on and I get "!@#$%"

Problem is not reproduceable.  This is on a fresh installation (not an upgrade)
of Red Hat Linux 9 with no modifications.

Suggestion: Format and do a fresh installation.

Closing bug with resolution: WORKSFORME

It's not fixed yet unfortunately: I did a fresh install of RH9 on a
newly-formatted harddrive partition, and immediately upon first boot observed
this problem.

The only thing that is unusual about my setup is that I configure the Dvorak
keyboard to be used as the default from the RH install program.

The broken behaviour is that Dvorak is not used in the text consoles, and that
CapsLock is broken in Xwindows, as described above.  (In fact, if there's a
keyboard switcher applet on the panel in Gnome, with Dvorak as its default
layout, when GNOME starts, the keyboard doesn't work at all with CapsLock on,
IIRC.  This doesn't happen if you add the applet after starting GNOME.)

At boot time I get the following messages:

Loading default keymap (dvorak):     [FAILED]
...
Starting key table: Loading keymap:  [FAILED]
Loading system font:                 [  OK  ]
                                     [FAILED]
...

i.e. the "system font" part says "OK" then "FAILED'.

I had a quick look in the rc.sysinit script and I'm not sure what's wrong, since
it seems that the dvorak layout files are present in their correct positions,
but I'm not sure.

Any help you can give would be appreciated.  I can't type qwerty anymore :-)

Created attachment 91017 [details]
XF86 log file

Doesn't show much, I don't think

Created attachment 91019 [details]
XF86Config file

Created attachment 91020 [details]
Relevant portion of /var/log/messages file

Additional info:

-- Using GNOME.
-- Value of LANG: en_US.UTF-8
-- Reproducible in: any Xwindows program (GNOME1, GNOME2, kde, plain X (e.g. xterm))

>Loading default keymap (dvorak):     [FAILED]
>...
>Starting key table: Loading keymap:  [FAILED]
>Loading system font:                 [  OK  ]
>                                     [FAILED]

These messages are console related messages which have nothing whatsoever
to do with XFree86 or how the keyboard works in XFree86.  The console
keyboard handling and the keyboard handling inside X are 100% separate
issues.

Please report this problem directly to XFree86.org via http://bugs.xfree86.org
so that the people who are experts with X keyboard mapping files can
investigate the problem and fix it if there is indeed a bug.

Once you've reported it upstream, feel free to add the URL of the upstream
bug report to this bug so upstream progress on the issue can be tracked.

Thanks.

Thanks for the pointers.  Just two questions:

(1) What can I do to get the console keyboard driver problem fixed?  (The
problem manifested itself on a fresh RH9 install.)  This probably needs to be
fixed by the RH packagers, since it seems to be a problem with the scripts or
with the file locations.

(2) Couldn't the XF86 keyboard handling problem be an issue with RedHat's
packaging of XF86-4.3 too?  I don't want to report it to them and have them
refer me back to you again.

Thanks...

I experienced the same problem of setting the dvorak layout as the default
during install and getting loadkeys error. I got around this by running
"loadkeys dvorak.map". Then I set 'KEYTABLE="dvorak"' to 'KEYTABLE="dvorak.map"'
in '/etc/sysconfig/keyboard' and rebooted and it was properly set. It would
appear that loadkeys command or the file layout of the keymap files in
'/lib/kbd/keymaps' has an issue because the '.map' suffix has never been
required before.

I just tested with Text Editor (gedit) in the Gnome Desktop and shifted chars
worked fine for me. This is after getting sysconfig/keymap set up to work though
this should be separate.

I was about to file a bug report about loadkeys but saw this report. Should I
dig into the source of loadkeys to find the difficulty?

Hi Scott,

It looks like Mike closed this report, so it would be good if you filed a bug
report.  I'm sure RedHat would also appreciate a source-level fix rather than
just a bug report too, if you are able to do that.

I'll test your suggestions and see if it fixes the X windows problem.  I guess
nobody at RH uses Dvorak.. :-)

Thanks, Scott!

Hmm, the terminal dvorak problem is fixed; the X win problem is not.

I wonder if I should report this up-stream to XFree86, or to Xwin, now that
Keith Packard has forked XFree86?  :-)  I'll probably wait for the dust to
settle a little bit.  (I imagine I'll have more success with Red Hat than with
XF86 right now.  Sorry to keep bothering you, Mike, but is there something else
I can do?)

Scott, do you have any further ideas as to what might be causing this?  Letters
work fine, but numbers and symbols work only in non-shifted mode when Caps Lock
is on.  Going "gkb_xmmap us" doesn't fix the problem.  

Here's the output in "xev", pressing and releasing "1" without Caps Lock on,
then "!" (Shift-1), then turning Caps Lock on, then pressing "1" and "!" again:

KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 946034, (565,477), root:(573,543),
    state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes:  "1"
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 946154, (565,477), root:(573,543),
    state 0x0, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes:  "1"
 
KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 948170, (565,477), root:(573,543),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 949226, (565,477), root:(573,543),
    state 0x1, keycode 10 (keysym 0x21, exclam), same_screen YES,
    XLookupString gives 1 bytes:  "!"
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 949314, (565,477), root:(573,543),
    state 0x1, keycode 10 (keysym 0x21, exclam), same_screen YES,
    XLookupString gives 1 bytes:  "!"
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 949609, (565,477), root:(573,543),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 950937, (565,477), root:(573,543),
    state 0x0, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 951017, (565,477), root:(573,543),
    state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 954633, (565,477), root:(573,543),
    state 0x2, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes:  "1"
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 954721, (565,477), root:(573,543),
    state 0x2, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes:  "1"
 
KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 956472, (565,477), root:(573,543),
    state 0x2, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:  ""
 
KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 957888, (565,477), root:(573,543),
    state 0x3, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes:  "1"
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 957976, (565,477), root:(573,543),
    state 0x3, keycode 10 (keysym 0x31, 1), same_screen YES,
    XLookupString gives 1 bytes:  "1"
 
KeyRelease event, serial 25, synthetic NO, window 0x3400001,
    root 0x48, subw 0x0, time 960136, (565,477), root:(573,543),
    state 0x3, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:  ""
 

Could this be a problem with incompatibility with my USB keyboard?  (MS Natural
Keyboard Pro.)  It worked in RH8.0.

Should I report this as a bug in a different module?

You should report the bug upstream as I mentioned already. The bug report
is closed as UPSTREAM which means it wont be touched by Red Hat at all,
at least until an upstream fix is available.

Your assessment that you'll get a faster fix out of Red Hat is wrong.
XFree86.org has several xkb experts of whom respond to issues that are
reported within days if not hours, and check them into CVS quite quickly.
In particular Ivan Pascal is a walking xkb bugfixer.  Red Hat on the other
hand has no xkb expert at all, and nobody interested in becoming one, so
xkb bugs sit here basically until the end of time until they're magically
fixed by coincidence in a new XFree86 release.

When I know a bug will have a much speedier fix from being reported upstream,
and/or I know a bug will have a very very low priority compared to all other
bugs against XFree86 in Red Hat bugzilla, I recommend the person report it
upstream, because I know they will see it fixed faster that way.  Those who
listen to the suggestion, generally do find that their problem gets fixed
faster too.

To be honest, the success rate of xkb bugs getting fixed upstream is so high
and so fast, that I wont even look into such reports anymore, I just recommend
the person file them upstream and close them UPSTREAM.  If the person files
them, they'll generally get fixed, and I monitor the CVS commits, so I generally
will backport the fix.

I won't put a gun to anyone's head of course.  ;o)  But my suggestion
will lead to a better resolution faster, so it is a good idea to follow.

Don't file any bugs at Xwin, as there is no coding going on and it'll likely
sit there forever untouched, or be recommended to file at XFree86 bugzilla.

Thank you for taking the time to explain that.  I'll report it upstream.

In case anyone else comes across this problem:

Ivan Pascal did indeed provide a fix for this problem -- here is the XF86 bug
report:

  http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=162

Thanks, Ivan (and Mike).

Reopening for integration into 4.3.0 packaging.

Patch backported to 4.3.0 and applied to 4.3.0-19 build in rawhide.