Bug#988540: im-config: breaks the keyboard configuration
Hi,
Your message made me to look into subtle points on Xsession etc. Thanks.
In order for me to track what I did/do with im-config, I added new section.
https://wiki.debian.org/Keyboard#Overview_of_keyboard_input
The environment in which im-config runs is complicated.
Let me ask a few questions and answer (with easy points first):
> -----Original Message-----
> From: Vincent Lefevre <vincent@vinc17.net>
...
> > 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.
What do you mean? Just hand written shell to start X? Or you start X server from
Linux virtual console manually?
im-config only supports xdm/gdm3/sddm/lightdm/lxdm/wdm... like starting of GUI
environment.
Also, are you running classic X server or xwayland under wayland? These are
important factor how system responds.
> 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.
70im-config_launch will end-up running /usr/share/im-config/data/78_none.rc. This is
empty file and do nothing.
This is explained in GUI dialog (if you used GUI) by /usr/share/im-
config/data/78_none.conf.
> > 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.
Yes. So we agree to be fine.
> > > 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 ] };
> [...]
Since I don't know exactly what is happening on your system and I know the upstream
has been aware of timing involved race condition bug, I am not surprised you are
getting somewhat deterministic results. (If you are interested, please read the
upstream bug mentioned in detail and test it like upstream.) Bugs around this XIM
thing is around for last 10 years or so if you trace the older bugs. That's why I
say to stay out.
https://bugzilla.redhat.com/show_bug.cgi?id=2013610
> > 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?
>
TBH, I never read X source around this part. So I don't know.
But guessing from upstream bug reports and my previous read of bug reports, some
special sequence key code is the source of the problem. The reordering of keyboard
input by the X server seems to be the issue. (Per upstream in multiple occasions)
> BTW, do you have an example of bug for something that works with XKB
> but not with XIM?
Hmmm... XKB is X keyboard extension. This is X's internal code (skipping kernel
processing of keyboard events) to process key events. X server sends resulting data
to application program using XIM when input method isn't used. XIM is some kind of
inter-process communication via pipe. That's my vague understanding. I may be wrong
in details. I updated https://wiki.debian.org/Keyboard as much to reduce confusion.
> 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.
The upstream has been complaining messy situation over the use of XIM for deadkey or
something similar. His code on bug report is test code to emulate incidents. So I
think it is pertinent. (Anyway, I don't understand all the glory of this
complication and I admit this is my best effort. If you have full understanding of
the situation, please propose explicit correction texts.)
> > 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.
Long term solution is not to use X keyboard Extension (XKB) (especially in
combination with ibus is bad idea). We are moving to Wayland and xwayland doesn't
process Xsession intentionally with reasons. So the use of input method is the
future.
https://wiki.debian.org/Wayland#Xresources_won.27t_load
> -----Original Message-----
> From: Vincent Lefevre <vincent@vinc17.net>
> ...
> > 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.
I am not going to argue how to get xkbcomp to work while ibus is active. I clarified
it by stating not to mix. That's not the future.
Regards,
Osamu
Reply to: