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

[Glynn Clements]

Kean Johnston wrote:

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

I think the real fix is for the rest of the key handling code to work
with any keysyms_per_keycode setting.

The fix might be as simple as fixing KEYSYM_INDEX.

According to §12.7 of the ICCCM:

	If the list (ignoring trailing NoSymbol entries) is a triple
	of KeySyms ``K1 K2 K3'', then the list is treated as if it
	were the list ``K1 K2 K3 NoSymbol''.

The get_symbol() function seems to have the correct logic:

  index = KEYSYM_INDEX(keymap_x11, group, level);
  if (index > keymap_x11->keysyms_per_keycode)
      return NoSymbol;

I suspect that the overflow test should be moved into KEYSYM_INDEX
itself.

> Armed with such
> a new map, it could then call XChangeKeyboardMapping().
> At least I *think* thats the right thing to do.

The keyboard mapping is a global configuration option; it shouldn't be
changed just to make life easier for a specific program.

The only programs which should use that function are xmodmap and
equivalents (e.g. a corresponding "control panel" GUI utility).

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