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

[Glynn Clements]

Kean Johnston wrote:

> 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?

I don't think the situation is quite as you describe.

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).

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?

If so, maybe they are using some higher-level input subsystem (e.g. 
for configuration, accessibility or localisation) which is performing
translation using the R6 server. That seems a more realistic
possibility.

-- 
Glynn Clements <glynn at gclements.plus.com>