keycodes all off by one with GTK and $DISPLAY pointing to an R5 server
glynn at gclements.plus.com
Sun Sep 18 10:35:16 PDT 2005
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)
I suspect that the overflow test should be moved into KEYSYM_INDEX
> 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>
More information about the xorg