On Wed, Mar 10, 2004 at 08:07:31PM +0200, Riku Voipio wrote: > So it isnt a keyboard or a xfree issue. Have you touched the keyboard > setting in the control center? Regional -> Keyboard layout. If you > have, can you look at the contents of: > > ~/.kde/share/config/kxkbrc > > If that file exists, it should have something like > > Rule=sun > Layout=type5 > > You can also try deleting the file, and kde should use whatever > keyboard layout is set in X.
Okay-- breakthrough. Initially, kxkbrc didn't exist, since we weren't messing with keyboard layouts in kde. I had initially looked through this when the problem first surfaced, but discarded it as a solution for two reasons: - Sun keyboards aren't available as an option through the configuration program - For all[1] users, settings will be shared across PCs and Sparcs(we're running a small computer lab which NFS mounts home directories and shares user info via NIS). So we don't want to use any architecture configuration settings on a per-user basis if we can at all avoid it(and it seems we should be able to). So just now I went in and turned on the "Enable Keyboard Layouts" option in KDE, which, since it lacks choices for sun keyboards, messed up the keyboard mapping completely. Logged out of KDE, and modified the kxkbrc file by hand to put in Rule=sun and Layout=type5. Logged back in, and the "b" key works fine. > If that doesnt work either, use the xev command both with and without > kde, and report what it giver for the 'b' key. FWIW, xev, under the non-working kde setup, reports 'b' for the b key-- although the system will tend to hang, and 'b' is still not returned in any application. But just before it does so, it gives another event: KeymapNotify event, serial 27, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 And actually, looking more closely, only a KeyRelease event is generated for the b key: KeyPress event, serial 27, synthetic NO, window 0xe00001, root 0x2b, subw 0x0, time 3085828, (81,51), root:(675,74), state 0x0, keycode 111 (keysym 0x62, b), same_screen YES, XLookupString gives 1 characters: "b" (Both of these events are returned without keyboard layouts enabled) On a working configuration, just the letter b is reported, and no KeymapNotify event is generated. This configuration is using fluxbox on an identical machine(though this one has two monitors, which is fairly irrelevant as it exhibits the same behavior): KeyPress event, serial 25, synthetic NO, window 0x1600002, root 0x49, subw 0x0, time 4115410, (78,101), root:(717,143), state 0x0, keycode 111 (keysym 0x62, b), same_screen YES, XLookupString gives 1 characters: "b" KeyRelease event, serial 25, synthetic NO, window 0x1600002, root 0x49, subw 0x0, time 4115498, (78,101), root:(717,143), state 0x0, keycode 111 (keysym 0x62, b), same_screen YES, XLookupString gives 1 characters: "b" This gives all gives me a work-around, and something I can implement for our guest account(and through a bit of scripting for all other accounts), but it is far from ideal, clearly. It looks to me like KDE is, for some reason, messing around with the keyboard mapping even though the keyboard layouts option has not been enabled. It also seems important that KDE has no option for sun/type5 keyboard layouts. [1] This sounds like an important detail, and in some ways it is. Except that the testing I've been doing to try and sort out this problem has been using the one user account which has a separate home directory on each machine, our guest account, which is local, and which could have machine architecture dependent settings if an app sets them up that way. (fwph) -- Frederick Heckel <[EMAIL PROTECTED]> GPG key: http://www.sccs.swarthmore.edu/~fwph/pubkey.txt ======================================================== fortune sez: All men have the right to wait in line.