Bug#235684: kde: "b" key in KDE on the sparc platform doesn't work
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
<fwph@sccs.swarthmore.edu>
GPG key: http://www.sccs.swarthmore.edu/~fwph/pubkey.txt
========================================================
fortune sez:
All men have the right to wait in line.
Reply to: