Your message dated Fri, 22 Apr 2022 15:06:41 +0200 with message-id <YmKoYWsxQnpz9o+E@jcristau-z4> and subject line Re: Bug#673023: kb geometry aliases can't refer to aliases has caused the Debian Bug report #673023, regarding kb geometry aliases can't refer to aliases to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 673023: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673023 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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
--- End Message ---
--- Begin Message ---Control: severity -1 wishlist On Tue, May 15, 2012 at 03:05:30PM +0100, Zefram wrote: > 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. Closing this report, I doubt such a change is going to happen in xkbcomp, but if it does it would have to happen upstream. Cheers, Julien
--- End Message ---
