Dear Maintainer, In unstable, after reboot, I hit kanji key, but ibus does not changed japanse to anthy. Stable release version changed japanse to anthy. So, I tried to fix. I do `ibus-daemon -xrd`. Then kanji key can change japanse to anthy. I set up same way between stable and unstable.
Thanks for your report. I see that you use i3, which reminds me of the Ubuntu bug <https://launchpad.net/bugs/1879352>. (Probably not related, since it works for you in bullseye.) Can you please show us the output of this command: ps aux | grep ibus I'd like to see the output both before and after your restarting of ibus-daemon.
Hi, I had similar experience of loosing Japanese input upon system updates. This happened only after system updates without rebooting. I never investigated the packages involved in this problem. Rebooing the system always fixed this problem for me based on my vague memory. I don't recall this happened before moving to Wayland. As you know, recent Debian system restarts some processes run under systemd upon system updates. Maybe some ibus or ibus-anthy or even xwayland related process may need to be included in the set of programs to be restarted to avoid rebooting the system. This is my speculation of this situation. If this is related to restarting xwayland startup scripts, Ubuntu bug mentioned by Gunnar may be related. Regards, Osamu
Hello, Thank you for your replying. ps aux | grep ibus yabuki 2839 0.7 0.0 382616 10620 ? Ssl 15:34 0:00 /usr/bin/ibus-daemon --daemonize --xim yabuki 2848 0.0 0.0 233820 7472 ? Sl 15:34 0:00 /usr/libexec/ibus-dconf yabuki 2849 0.7 0.1 2115168 100168 ? Sl 15:34 0:00 /usr/libexec/ibus-ui-gtk3 yabuki 2850 1.4 0.1 1875180 89968 ? Sl 15:34 0:00 /usr/libexec/ibus-extension-gtk3 yabuki 2852 0.2 0.1 1794608 78384 ? Sl 15:34 0:00 /usr/libexec/ibus-x11 --kill-daemon yabuki 2855 0.0 0.0 233760 7776 ? Sl 15:34 0:00 /usr/libexec/ibus-portal yabuki 3072 0.8 0.0 281972 26032 ? Sl 15:34 0:00 python3 /usr/share/ibus-anthy/engine/main.py --ibus yabuki 3967 0.0 0.0 159976 7700 ? Sl 15:35 0:00 /usr/libexec/ibus-engine-simple yabuki 3974 0.0 0.0 4484 2232 pts/1 S+ 15:35 0:00 grep ibus ibus-anthy settings reflected. but ibus-setting did not reflect. My ibus settngs : see atatch images.
Sorry I forgot attaching restarted status. Now ibus-daemon can use Kanji(Zenkaku_Hankaku) key. $ ibus-daemon -xrd $ ps aux | grep ibus yabuki 8643 1.6 0.0 382764 10760 ? Ssl 15:51 0:00 ibus-daemon -xrd yabuki 8659 0.0 0.0 233820 8056 ? Sl 15:51 0:00 /usr/libexec/ibus-dconf yabuki 8660 1.8 0.0 543364 45288 ? Sl 15:51 0:00 /usr/libexec/ibus-ui-gtk3 yabuki 8661 12.0 0.0 267756 29272 ? Sl 15:51 0:00 /usr/libexec/ibus-extension-gtk3 yabuki 8663 0.6 0.0 187120 20996 ? Sl 15:51 0:00 /usr/libexec/ibus-x11 --kill-daemon yabuki 8668 0.0 0.0 233756 7444 ? Sl 15:51 0:00 /usr/libexec/ibus-portal yabuki 8687 2.0 0.0 281960 25156 ? Sl 15:51 0:00 python3 /usr/share/ibus-anthy/engine/main.py --ibus yabuki 8712 0.0 0.0 159976 7676 ? Sl 15:51 0:00 /usr/libexec/ibus-engine-simple yabuki 8739 0.0 0.0 4484 2240 pts/1 S+ 15:51 0:00 grep ibus
Thanks for additional info, Yukiharu YABUKI. Unfortunately it didn't bring us closer to an explanation, since /usr/bin/ibus-daemon --daemonize --xim is basically the same as ibus-daemon -xrd Hmm.. If I understand it correctly, a reboot only is not sufficient for the OP to work around this issue.
Hi, How I do check where started ibus read the ibus configration? I did setup with im-config for ibus. It seems to me that ibus-daemon re-read my home configration. On Thu, 7 Jul 2022 21:51:23 +0200 Gunnar Hjalmarsson <gunnarhj@debian.org> wrote:
What exactly do you mean by "home configuration"? Actually, with im-config installed, there shouldn't be a need for any kind of configuration in your $HOME. ibus should still be started and properly configured. Do you possibly have some extra configuration which conflicts with im-config?
Hi, I did execute im-config. Then I choose ibus. So im-config made ~/.xinputrc ~/.xinput contains ```` # im-config(8) generated on Sat, 30 Jul 2022 00:23:42 +0900 run_im ibus # im-config signature: f863f9b702709aac186b408cc110240c - ```
Ok, that should not be a problem. Explicitly choosing ibus just makes sure that im-config starts/configures ibus rather than some other IM framework (e.g. fcitx5) if that would be installed.
Hi, So you are still suffering ... Strange. Do you have the same issue with any GTK program? Say lxterminal ? If program using ibus/anthy is GTK, it doesn't access such daemon. It access library instead. So the symptom reported is strange. Are you suffering this problem with rxvt or xterm? Please double check if your power-down is the real one (not sleep button) by shutting down system from the virtual Linux console command line (ALT-CTRL-F3 etc.) with "sudo shutdown -h now" or similar. Osamu
Hi, Ok, I'll install lxterminal(lxterm) My default terminal is uxterm. I go over this issue with uxterm and lxterm. Both of these terminal do not change between "日本語 - anthy" and "日本語 - japanese". I found one more strange behavior. odd number I did `ibus-daemon -rxd` It works fine. but even number I did `ibus-daemon -rxd` does not accept ctrl+j. It's time to learn how to use debuginfod. ... I need to help how to setup and debug. I'll try to ask mailling list. When I reboot my desktop machine, I do `reboot` command.
Hi, Yabuki-san and Gunnar,
Gunnar,
im-config has gone through several changes last several years to accommodate non-ibus
for GNOME on wayland. We may have introduced some regression for X based system.
Since I don't use non-wayland system, we may have over looked problem there.
One point I am worried is ibus daemon starting process. The currently, we don't set
"-r" to replace existing daemon. Does im-config starts daemon twice? Should we add
"-r" option there? (I know it should not start twice.)
My GNOME start up has several start ups of ibus daemon. Do we need similar ?
```
$ journalctl -a -b |grep 'ibus'
Jul 31 15:35:25 goofy /usr/libexec/gdm-wayland-session[1037]: dbus-daemon[1037]:
[session uid=116 pid=1037] Activating service name='org.gtk.vfs.Daemon' requested by
':1.22' (uid=116 pid=1366 comm="ibus-daemon --panel disable")
Jul 31 15:35:25 goofy /usr/libexec/gdm-wayland-session[1037]: dbus-daemon[1037]:
[session uid=116 pid=1037] Activating service name='org.freedesktop.portal.IBus'
requested by ':1.22' (uid=116 pid=1366 comm="ibus-daemon --panel disable")
Jul 31 15:35:25 goofy /usr/libexec/gdm-wayland-session[1037]: dbus-daemon[1037]:
[session uid=116 pid=1037] Activating service name='org.freedesktop.portal.IBus'
requested by ':1.35' (uid=116 pid=1514 comm="ibus-daemon --panel disable -r --xim")
Jul 31 15:35:32 goofy dbus-daemon[1749]: [session uid=1000 pid=1749] Activating
service name='org.freedesktop.portal.IBus' requested by ':1.61' (uid=1000 pid=1986
comm="/usr/bin/ibus-daemon --panel disable")
```
Yabuki-san,
I don't understand your situation well. Maybe telling me minimum set up to reproduce
under KVM may be a good idea. Anyway, ....
`ctrl+j` key-binding sounds like something ibus-anthy preference menu sets if you
ever set it so or it is the default. (I may have changed it on my system so I can't
check for you ...) That's after having working ibus-anthy and using anthy as input
method. It only changs operational mode of anthy. You set it through anthy's
preference menu.
Switching between "日本語 - anthy" and "日本語 - japanese" sounds like switching between
different ibus engines. That's usually SUPER-SPACE and its binding is set by ibus-
setup for pure classic X system. (I usually don't bother enabling "日本語 - japanese"
as input method since I need more than Hiragana ... You can see which methods are
active by looking at ibus-setup GUI selection screen.)
Checking running processes on your system with "sudo ps axjf" may give you some idea.
As I checked on GNOME/wayland, it starts ibus daemon without --xim.
(excuse me for folded lines)
```
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
0 2 0 0 ? -1 S 0 0:00 [kthreadd]
2 3 0 0 ? -1 I< 0 0:00 \_ [rcu_gp]
... skip
0 1 1 1 ? -1 Ss 0 0:01 /sbin/init
... skip
1 1719 1719 1719 ? -1 Ss 1000 0:00
/lib/systemd/systemd --user
... skip
1719 1983 1983 1983 ? -1 Ss 1000 0:00 \_ sh -c
/usr/bin/ibus-daemon --panel disable $([ "$XDG_SESSION_TYPE" = "x11" ] && echo "--
xim")
1983 1986 1986 1983 ? -1 Sl 1000 0:20 | \_
/usr/bin/ibus-daemon --panel disable
1986 2105 1986 1983 ? -1 Sl 1000 0:00 | \_
/usr/libexec/ibus-dconf
1986 2106 1986 1983 ? -1 Sl 1000 0:03 | \_
/usr/libexec/ibus-extension-gtk3
1986 2183 1986 1983 ? -1 Sl 1000 0:12 | \_
python3 /usr/share/ibus-anthy/engine/main.py --ibus
2183 6808 1986 1983 ? -1 Z 1000 0:00 | | \_
[python3] <defunct>
1986 2898 1986 1983 ? -1 Sl 1000 0:00 | \_
/usr/lib/ibus-mozc/ibus-engine-mozc --ibus
...
1719 5490 5490 5490 ? -1 Ssl 1000 0:24 \_
/usr/libexec/gnome-terminal-server
5490 5508 5508 5508 pts/0 7133 Ss 1000 0:00 | \_ bash
5508 7133 7133 5508 pts/0 7133 S+ 1000 0:00 | | \_
/usr/bin/mc -P /tmp/mc-osamu/mc.pwd.5508
7133 7135 7135 7135 pts/1 7135 Ss+ 1000 0:00 | | \_
bash -rcfile .bashrc
5490 7490 7490 7490 pts/2 8568 Ss 1000 0:00 | \_ bash
7490 8568 8568 7490 pts/2 8568 S+ 0 0:00 | | \_ sudo
ps axjf
8568 8569 8569 8569 pts/3 8570 Ss 0 0:00 | | \_
sudo ps axjf
8569 8570 8570 8569 pts/3 8570 R+ 0 0:00 | |
\_ ps axjf
5490 7951 7951 7951 pts/4 8044 Ss 1000 0:00 | \_ bash
7951 8044 8044 7951 pts/4 8044 S+ 1000 0:00 | | \_
/usr/bin/mc -P /tmp/mc-osamu/mc.pwd.7951
8044 8046 8046 8046 pts/5 8046 Ss+ 1000 0:00 | | \_
bash -rcfile .bashrc
5490 8238 8238 8238 pts/6 8238 Ss+ 1000 0:00 | \_ bash
...
```
Osamu
Aoki-san.
Thank you for your suggestion.
I did 'ps axjf'. This output was too big. I selected from output.
1) gdm3
1 1087 1087 1087 ? -1 Ssl 0
0:00 /usr/sbin/gdm3 1087 2337 1087 1087 ? -1
Sl 0 0:00 \_ gdm-session-worker [pam/gdm-password] 2337
2532 2532 2532 tty2 2532 Ssl+ 1000 0:00
\_ /usr/libexec/gdm-x-session --register-session --run-script i3 2532
2534 2532 2532 tty2 2532 Sl+ 1000 7:13
\_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gd 2532
2604 2532 2532 tty2 2532 S+ 1000 0:04 \_ i3
2604 2690 2690 2690 ? -1 Ss 1000
0:00 \_ /usr/bin/ssh-agent /usr/bin/im-launch i3
2) ibus-daemon
1 385641 385641 385641 ? -1 Ssl 1000 0:15
ibus-daemon -xrd 385641 385651 385641 385641 ? -1 Sl
1000 0:00 \_ /usr/libexec/ibus-dconf 385641 385652 385641
385641 ? -1 Sl 1000 0:03 \_ /usr/libexec/ibus-ui-gtk3
385641 385653 385641 385641 ? -1 Sl 1000 0:04
\_ /usr/libexec/ibus-extension-gtk3 385641 385679 385641
385641 ? -1 Sl 1000 0:00
\_ /usr/libexec/ibus-engine-simple 385641 385777 385641
385641 ? -1 Sl 1000 0:09 \_
python3 /usr/share/ibus-anthy/engine/main.py --ibus 1 385655 385641
385641 ? -1 Sl 1000 0:11 /usr/libexec/ibus-x11
--kill-daemon
3) ps axjf
1 8145 8144 8144 ? -1 S 1000
0:00 /bin/sh -c uxterm 8145 8146 8144 8144 ? -1
S 1000 0:00 \_ xterm -class UXTerm -title uxterm -u8 8146
8150 8150 8150 pts/7 845149 Ss 1000 0:00 \_ bash
8150 845149 845149 8150 pts/7 845149 S+ 0 0:00
\_ sudo ps axjf 845149 845293 845293 845293 pts/19 845294 Ss
0 0:00 \_ sudo ps axjf 845293 845294 845294 845293
pts/19 845294 R+ 0 0:00 \_ ps axjf
It's possible, of course. OTOH I just installed an XFCE system (Xubuntu 22.04), installed ibus-anthy, and things just work. Even if my keyboard does not include any special Japanese keys... It is the default. That distinction is important. Ctrl+J for toggling between Hiragana and latin typing, while the active input method is Anthy, vs. Super+Space for switching to some other input source.
Hi, Anyway, since you are running relatively minor desktop with i3, this may be the reason. Proper working of im-config rely on xdm/kdm like start up. Since it is almost impossible to figure-out when did it broke, the best thing is to set up testing VMs. Then try different DE settings: GNOME -> KDE -> LXDE -> i3 Once you know when things break, we have better chance to identify issue. Good luck. Osamu
Hi, When I was doing something else, I accidentally see funny things in /usr/lib/systemd/user, we now have 2 files: * org.freedesktop.IBus.session.generic.service.in * org.freedesktop.IBus.session.GNOME.service.in This seems to come from new commits (salsa) e6e270123 (Gunnar Hjalmarsson 2022-03-14 09:25:47 +0100 1) in the source tree ibus/bus/services I am wondering if we set correctly before calling ? In the source tree there, I see: The first one was used before. Now we don't seem to install the first one but install other 2 files. Any though?
Hi, When I was doing something else, I accidentally see funny things in /usr/lib/systemd/user, we now have 2 files: * org.freedesktop.IBus.session.generic.service.in * org.freedesktop.IBus.session.GNOME.service.in This seems to come from new commits (salsa) e6e270123 (Gunnar Hjalmarsson 2022-03-14 09:25:47 +0100 1) in the source tree ibus/bus/services I am wondering if we set correctly before calling ? In the source tree there, I see: The first one was used before. Now we don't seem to install the first one but install other 2 files. Any though?
The first one is installed as /usr/share/dbus-1/services/org.freedesktop.IBus.service $ cat /usr/share/dbus-1/services/org.freedesktop.IBus.service [D-BUS Service] Name=org.freedesktop.IBus Exec=/usr/bin/ibus-daemon --replace --panel disable --xim
The first one is installed as /usr/share/dbus-1/services/org.freedesktop.IBus.service $ cat /usr/share/dbus-1/services/org.freedesktop.IBus.service [D-BUS Service] Name=org.freedesktop.IBus Exec=/usr/bin/ibus-daemon --replace --panel disable --xim
Hi, Oh, wring file names in my original post and ... My original concern for installed systemd configuration files are there. One for GNOME, one for others. And others seems to relyon some variable substitution. Is it working correctly? /usr/lib/systemd/user/ has followings: Osamu
Hi, Oh, wring file names in my original post and ... My original concern for installed systemd configuration files are there. One for GNOME, one for others. And others seems to relyon some variable substitution. Is it working correctly? /usr/lib/systemd/user/ has followings: Osamu
Hi again, Osamu! At last I understand what you are concerned about. Hmm.. While the GNOME one is used in GNOME sessions, it looks to me as if the generic one is not used at all. $ systemctl --user list-unit-files | grep IBus org.freedesktop.IBus.session.generic.service static - org.freedesktop.IBus.session.GNOME.service enabled enabled If I put "none" in the ~/.xinputrc file on my Xubuntu installation, no ibus-daemon process is started at login. And if the generic service file isn't used, there shouldn't be a conflict with im-config. It would of course be good to know the intention with the org.freedesktop.IBus.session.generic.service file.
Hi again, Osamu! At last I understand what you are concerned about. Hmm.. While the GNOME one is used in GNOME sessions, it looks to me as if the generic one is not used at all. $ systemctl --user list-unit-files | grep IBus org.freedesktop.IBus.session.generic.service static - org.freedesktop.IBus.session.GNOME.service enabled enabled If I put "none" in the ~/.xinputrc file on my Xubuntu installation, no ibus-daemon process is started at login. And if the generic service file isn't used, there shouldn't be a conflict with im-config. It would of course be good to know the intention with the org.freedesktop.IBus.session.generic.service file.
Hi, I have realized that this issue happended in GDM3 environment. In LightDM environment, this issue does not happend.
Hmm.. So you have GDM3 installed, which depends on the core GNOME
packages including gnome-session-common. Maybe that GNOME user service
systemd file has something to do with it, after all.
Can we do an experiment?
1. Change your ~/.xinput file to "none" using this command:
im-config -n none
2. Change your default display manager to GDM3.
3. Reboot and log in.
4. Find out if ibus-daemon is still running:
ps aux | grep ibus
Hi, One think I noticed long time ago for GDM3 is it doesn't seem to use input method. Now GNOME set up ibus infrastructure, it may be killing and cleaning input method to provide clean start for GNOME. I didn't check but it may be worth checking situation. Maybe this is something we can only deal as documenting limitation and side effects for GDM3. Just a thought...
Hi Yabuki-san, Please check if new im-config 0.53-1 solves your issue. We included patch proposed at: https://salsa.debian.org/input-method-team/im-config/-/merge_requests/16 TBH, I am not even sure this is the right solution to your problem or any others. I have no idea how X session startup code are used by different DMs and I don't have enough resource (or time) to investigate this in depth. (GDM3 vs. LightDM) At least, this looks like a harmless patch which might solve double start of ibus. Regards, Osamu
Hi Yabuki-san, Please check if new im-config 0.53-1 solves your issue. We included patch proposed at: https://salsa.debian.org/input-method-team/im-config/-/merge_requests/16 TBH, I am not even sure this is the right solution to your problem or any others. I have no idea how X session startup code are used by different DMs and I don't have enough resource (or time) to investigate this in depth. (GDM3 vs. LightDM) At least, this looks like a harmless patch which might solve double start of ibus. Regards, Osamu
For the record I installed gdm3 (and a lot of dependencies) on my Xubuntu test installation, and accomplished these steps: Found that ibus-daemon was not started. Tested with logging in to both a Xubuntu and a Cinnamon session. Actually I tried to use i3 too, but the barrier to set it up proved to be high, and I'm not willing to spend the time needed for that. So even if GDM is used as login manager, it's unlikely that the presence of the systemd service files interferes with the IBus setup for non-GNOME sessions. It's possible that there is some issue with how i3 interacts with ibus or im-config or both, and I'd say that the i3 maintainers should better get involved if the intention is that input methods can be conveniently configured also with i3. Marked this bug as affecting i3.