Bug#988540: im-config: breaks the keyboard configuration
On 2022-05-25 15:54:13 +0900, Osamu Aoki wrote:
> > 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?
I normally use the lightdm display manager to start X (or in case of
breakage, I start X from a Linux virtual console with "startx"). This
has the effect to run my .xsession script. After some settings, it
starts my window manager FVWM2 (actually a wrapper to handle ssh-agent),
from which applications are run. FVWM2 is just a window manager, not a
desktop environment.
> im-config only supports xdm/gdm3/sddm/lightdm/lxdm/wdm... like
> starting of GUI environment.
When installed, im-config is started by default via the Xsession
mechanism (which is used at least when one doesn't have a desktop
environment).
> Also, are you running classic X server or xwayland under wayland?
A classic X server. I also often use remote X applications (for
which there are no issues with my XKB settings, but I don't know
about ibus / im-config, in particular if it relies on environment
variables that are not passed via SSH).
> > [...] 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.
IIRC, when I tried it, I didn't use the GUI.
> > > > 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
If you mean this bug, the user is trying to do things that are not
possible with XKB. So I'm not surprised that there may be issues
in such a case.
> > > 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)
This has nothing to do with non-ASCII. Perhaps there might be issues
with things like dead keys or the compose key (as a sequence of keys
is involved) if ibus does something unexpected by the X server. But
this is orthogonal to the character set.
> > 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.)
Do you have the bug report?
If you mean Red Hat Bugzilla – Bug 2013610:
* In the first video, the user apparently uses a method to
automatically output a space after a period and complains
that they are reversed. But that's 2 characters instead of
one, i.e. this is not possible with XKB settings (or
something unusual I'm not aware of). So, off-topic.
* In the second video, one can see some kind of prediction.
Again, this is not possible with XKB. So, off-topic.
--
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: