keycodes all off by one with GTK and $DISPLAY pointing to an R5 server

[Kean Johnston]

> For a start, if I remap a key with xmodmap, existing GTK apps
> instantly use the new keysym. That implies that GTK doesn't have
> keycodes hardcoded (GTK tends to pay little heed to specifications,
> but it isn't that badly screwed).
I didn't say it hard-coded keycodes, just that it *uses* keycodes,
instead of keysyms. To be honest, I dont know which is the best
approach. But the GDK code certainly has stuff in it that has
very explicit knowledge of keysyms. To wit, gdkkeysyms.h,
which lists most of they keys found in keysymdef.h but using
different names (GDK_Home, for example, instead of XK_Home).
There's certainly a great deal of voodoo going on in
gdk/x11/gdkkeys-x11.c. So its less well behaved than you'd want.
Of course, those codes havent changed in decades, so its more
than likely safe, but I find whenever the same information is
repeated twice, you're bound to run into trouble one day.

> Are you sure that there aren't other factors involved? Are the GTK
> apps in question using e.g. Gnome? Are you running individual
> applications on the R5 server but from a desktop environment which is
> using the R6 server?
As sure as I can be. I tried the test without even starting a
window manager, just a single xterm from which I launched vim
(which was compiled to use gtk2). The same problem exists with
Mozilla (which also uses gtk2). The actual R5 serve is as bare
bones as you can get. Certainly, the X terminal is older than
I am alomost, so doesn't do any funky stuff at all.

Just to prove to myself that I'm not totally crazy, I fired
up the xedit from X.org 6.8.2 in the same environment, and
'q' and Tab behave just fine. So it certainly is looking
like a GDK/GTK problem. Perhaps I should move this query to
that list. But it still doesn't explain why the R5 xev
and the X.Org 6.8.2 xev report different keycodes for q and
tab. Wel actually, why everything is shifted by 1. I just
discovered that ESCAPE, which seems to be the lowest keycode,
has different keycodes too:

R5 server, R5 xev: ESC = keycode 8
R5 server, R6 xev: ESC = keycode 8
R6 server, R5 xev: ESC = keycode 9
R6 server, R6 xev: ESC = keycode 9

So it really looks like something, somewhere is doing a +1.
Or some constant like MIN_KEYCODE is different, or something.
But what really has me puzzled is why, in the two GTK apps
mentioned, only the 'q' and 'Tab' keys seems to be affected.

Even if someone doesnt know off the top of their heads what
could be causing this, pointers on how (and where) to debug
would also be greatly appreciated.

Kean