Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Description of problem: I upgraded to Phoebe 8.0.94 from RH8.0. Now, when Caps Lock is on, regular alphabetic characters still work fine (Shift's action is reversed), but numeric characters remain numeric even when shift is pressed (e.g. it's impossible to type % or $ when Caps Lock is on), meaning those keys are "stuck" in "non-Shifted" state, and punctuation is "stuck" in "Shifted" state (e.g. it's impossible to type an underscore, pressing it with or without Shift down gives a dash). I upgraded to XFree86-4.3.0-3 from RawHide, with no effect. Rebooting does not fix the problem. There is a new problem on bootup where "Loading default keymap" is reported as "[FAILED]" twice -- I don't know if this is related or not. Version-Release number of selected component (if applicable): XFree86-4.3.0-3; Phoebe 8.0.94 How reproducible: Always Steps to Reproduce: As above. Additional info:
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.