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

[Kean Johnston]

> If there's a bug in KEYSYM_INDEX, I can imagine it overwriting the 'q'
> slot rather than the Shift+Tab slot.
Turns out the bug is that GDK assumes that they keymap has an
even number of keysysms per keycode. It deals with "groups",
and the KEYSYM_INDEX specifically rounds things up to even
group numbers. The problem is that the server is reporting
the keysyms_per_keycode as 3. Thus, the GTK algorithm is
overwriting keysyms.

I guess the real fix is to have GTK detect, as early as
possible, a non-even numbered keysyms_per_keycode, and
round it up to the next even number so that the rest of
the key handling code works as expected. Armed with such
a new map, it could then call XChangeKeyboardMapping().
At least I *think* thats the right thing to do. I'm gonna
wait for Owen to chime in before I dive into making a patch.

Kean

PS Owen, I'm off to file a bug now as you requested.