Bug#673023: kb geometry aliases can't refer to aliases

[Zefram <zefram@fysh.org>]

Package: x11-xkb-utils
Version: 7.5+5
Severity: important

XKB key aliases can be defined in the geometry section, as well as in
the keycodes section, to effect a separation of concerns.  However, this
separation fails because xkbcomp doesn't allow key aliases in the geometry
section to freely use the key names supplied by the keycodes section.
Specifically, the geometry section can't use names that the keycodes
section defined as aliases.  This contrasts with the symbols section,
which can use key names defined directly or as aliases interchangeably.
Test case:

$ cat t0.xkb
xkb_keymap {
xkb_keycodes "test_keycodes" {
        minimum = 8;
        maximum = 255;
        <CFOO> = 10;
        <CBOX> = 11;
        alias <CBAR> = <CBOX>;
        <CBAZ> = 12;
        <CQQQ> = 13;
        alias <CQUX> = <CQQQ>;
};
xkb_types "complete" { include "complete" };
xkb_compatibility "complete" { include "complete" };
xkb_symbols "test_symbols" {
        key <CFOO> { [ a, A ] };
        key <CBAR> { [ b, B ] };
        key <GBAZ> { [ c, C ] };
        key <GQUX> { [ d, D ] };
};
xkb_geometry "test_geometry" {
        alias <GBAZ> = <CBAZ>;
        alias <GQUX> = <CQUX>;
};
};
$ xkbcomp t0.xkb t0.xkm
Warning:          Attempt to alias <GQUX> to non-existent key <CQUX>
                  Ignored
Warning:          Key <GQUX> not found in test_keycodes keycodes
                  Symbols ignored
Warning:          No symbols defined for <CQQQ> (keycode 13)

Observe that the symbols section uses the directly-defined <CFOO> and
the alias <CBAR> equivalently without trouble, but when the geometry
section tries to use the directly-defined <CBAZ> and the alias <CQUX>
equivalently the latter fails.  The alias <GQUX> is then not usable by
the symbols section.

This problem occurs for real around the "menu" key of 104/105-key PC
keyboards.  It is known as both <MENU> and <COMP>, the latter apparently
referring to a "compose" function.  Its keycode varies according to how
the keyboard is accessed: 117 in the "standard" xfree86 keycode set,
and 135 in the evdev driver.  Both the xfree86 and evdev keycode files
define both names, one directly and one as an alias, but they differ
on which one is done which way.  It shouldn't matter that they differ,
but the result is that a geometry file can't reliably refer to this key
at all.  The only workaround is to have two versions of the geometry file,
the choice between them having to be made to match the keycodes file.
This is obviously a failure of the separation of concerns that the
multi-section mechanism was intended to achieve.

(The geometry section *can* use alias key names for its picture-drawing
part, just not for creating aliases.  I've run into this problem
specifically when attempting to have the geometry section provide
systematic layout-based key names, so that the symbols section can assign
keysyms based on keys' locations rather than on their nominal functions.)

-zefram