keycodes all off by one with GTK and $DISPLAY pointing to an R5 server
otaylor at redhat.com
Sat Sep 17 15:31:35 PDT 2005
On Fri, 2005-09-16 at 14:04 -0700, Kean Johnston wrote:
> Hi everyone,
> I am having a really difficult time understanding this problem.
> Here's what I do:
> On 6.8.2 server, I run both an R5 'xev' and the 6.8.2 'xev'.
> If I press the TAB key, in both cases I get keycode 23,
> keysym 0xff09, Tab. If I press the 'q' key I get keycode
> 24, keysym 0x71, q. Life is good.
> Now I repeat the test running on a X terminal, or on an
> old R5 server, and things fall apart. If I press the TAB
> key, I get keycode 22, keysym 0xff09, Tab. If I press the
> 'q' key I get keycode 23, keysym 0x71, q. Notice that the
> keycodes are all off-by-one, but teh keysyms are correct.
> This causes considerable problems for GTK apps, which
> seem to want to use the keycode, not the keysym. Thus,
> for example, in Mozilla, pressing the 'q' key yields a
> TAB for me. Not so useful that! Same with gvim.
> So, I have two questions really: Why is everything off-by-one,
> and why does GTK use the keycode, and not the keysym?
All X applications use the keycode not the keysym, in one sense;
only the key code is sent from the server to the client and
the client converts the key code to a key symbol.
GTK+ has it's own code for converting between key codes and
key symbols; this is done for various reasons. Among other
things, GTK+ needs to understand the keycode => keysymbol
relationship to do accelerator matching properly, so we
might as well use that code all the time. It's not much good
if basic keyboard input works, but keybindings and accelerators
go screwy in odd ways.
There are separate code paths in GTK+ for XKB and non-XKB
servers. The non-XKB server path took some iterations to get
right, but has had a fair bit of testing now and works to
the best of our knowledge.
There's probably just something about your keymap that is
confusing the code in GTK+. If you file a bug in bugzilla.gnome.org
and attach the output of 'xmodmap -pk', someone may be
able to figure it out from that. Otherwise, you are pretty
much on the hook yourself for debugging what's going wrong.
The relevant code is the non-XKB portion of
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg