[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#673023: marked as done (kb geometry aliases can't refer to aliases)

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 owner@bugs.debian.org
immediately.)


-- 
673023: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673023
Debian Bug Tracking System
Contact owner@bugs.debian.org 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 ---
Reply to: