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

[Glynn Clements]

Kean Johnston wrote:

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

Keysyms are standardised, so that shouldn't be a issue.

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

Keycodes are hardware specific, and tend to be based on the physical
layout of the keyboard. E.g. on mine, Q = 24, W = 25, E = 26 and so
on. For an AZERTY keyboard, the A+Z keys would have the same codes as
Q+W do on a QWERTY keyboard. Different keyboards (e.g. systems other
than PCs) may use completely different codes.

Anything which relies upon specific keys having specific codes is
completely broken. I doubt that GTK is that broken.

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

One possibility is that it's an Xkb issue. The R5 server won't support
Xkb, but GTK appears to rely upon it, e.g.:

  if (keymap_x11->xkb_desc == NULL)
    {
      keymap_x11->xkb_desc = XkbGetMap (xdisplay, XkbKeySymsMask | XkbKeyTypesMask, XkbUseCoreKbd);
      if (keymap_x11->xkb_desc == NULL)
	g_error ("Failed to get keymap");

      XkbGetNames (xdisplay, XkbGroupNamesMask, keymap_x11->xkb_desc);
    }

The code in question is guarded by "#ifdef HAVE_XKB", but that's a
compile-time issue. You don't know whether the server supports Xkb
until run time.

I don't know how the Xkb* functions behave if the server doesn't have
the extension.

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