Bug#988540: im-config: breaks the keyboard configuration
On 2022-05-24 22:54:01 +0900, Osamu Aoki wrote:
> > > Users may no longer be able to use xterm **reliably for some
> > > non-ASCII inputs** when ibus is **activated**.
> >
> > I'm wondering what you mean by that. I recall that:
> >
> > 1. If im-config is run after my XKB settings, then my keyboard
> > configuration is broken (probably overridden by im-config's
> > own settings). This means that ibus is activated, right?
>
> Yes. (To be precise, your XKB settings are *ignored*. Since keyboard
> inputs goes through ibus to reach xterm. ibus is not run under your
> XKB settings nor under its influence. I guess this is the situation
> but I haven't investigated exact situation.)
This is incorrect. XKB settings are ignored when running im-config,
but they are not ignored by changing them with xkbcomp after that.
> ibus activation may be by the default setting of im-config or by the
> Desktop environment such as recent GNOME.
I recall that I do not use any desktop environment. But im-config
provides /etc/X11/Xsession.d/70im-config_launch, which is sourced
automatically when one logs in, and there is *no way* for the end
user to disable it. The user's $HOME/.xsessionrc file is sourced
before 70im-config_launch, so that this could be a way to let the
user choose (if properly documented), e.g. via setting or not some
shell variable. However, "im-config -n none" may be sufficient.
> If you want to use classic XKB setting, just don't activate ibus.
> (or don't install ibus.)
If "im-config -n none" has the effect that ibus is not activated,
this is fine. Otherwise, there would be issues on multiuser machines,
where ibus and im-config may be installed for users who need them.
> > So, if ibus is activated (see (1)), this would
> > mean that it shouldn't affect xterm, even for most non-ASCII
> > inputs (I recall that I use accented letters, possibly via
> > dead keys, and math symbols: xterm is receiving the Unicode
> > character correctly, so I wonder why it would depend on the
> > code point).
>
> I don't know what do you mean by code point.
Unicode code point. This is how XKB maps the keyboard, with
translations from a key code to a Unicode character (given
by some name or in hexadecimal). For instance, I have:
[...]
key <AC01> { [ a, A, ae, AE ] };
key <AC02> { [ s, S, ssharp, U2211 ] };
key <AC03> { [ d, D, dagger, downarrow ] };
key <AC04> { [ f, F, U2500, U2502 ] };
key <AC05> { [ g, G, U250C, U251C ] };
key <AC06> { [ h, H, U2510, U2524 ] };
key <AC07> { [ j, J, U2514, U252C ] };
key <AC08> { [ k, K, U2518, U2534 ] };
key <AC09> { [ l, L, sterling, U253C ] };
[...]
> Some particular keyboard inputs may cause problem but mostly
> functional for keyboard -> ibus -> XIM -> xterm path. If you re-read
> my updated page, I describe this subtle situation carefully. Please
> read https://wiki.debian.org/Keyboard .
This is not satisfactory. What do you mean by "pass processed data"
for XIM clients? i.e. what kind of data? And why non-ASCII?
BTW, do you have an example of bug for something that works with XKB
but not with XIM?
What is described under "There have been frequent and persistent bugs
around this combination as discussed in Red Hat Bugzilla – Bug 2013610."
is off-topic, because such input methods are not possible with XKB.
> Especially, I
> address your concern at
> https://wiki.debian.org/Keyboard#Multi-language_keyboard_configuration_strategy
But if some applications start to support ibus only because XKB is
obsolete, "im-config -n none" is not a long-term solution.
> XIM bug for ibus seems to impact particular combination of input sequences anyway.
>
> > [*] in case of testing, bug 661295 needs to be taken into account,
> > i.e. one should test by starting xterm after any config change.
>
> No no no... let's not create unmanageable system.
??? I'm just saying that if you want to test the behavior and see
that xterm doesn't work, you must not blindly deduce that this is
a bug in XIM or whatever, because xterm or libx11 has its own bugs
and you may actually see that.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: