I'm not sure which layer of the input stack is to blame, so let's start with the one on the top.

gnome-desktop is a module for drawing wallpapers basically, not the right component.

gnome-session has this code:

        {•
                gchar *ibus_path;•
•
                ibus_path = g_find_program_in_path("ibus-daemon");•
•
                if (ibus_path) {•
...
                        p = g_getenv ("XMODIFIERS");•
                        if (!p || !*p)•
                                p = "@im=ibus";•
                        gsm_util_setenv ("XMODIFIERS", p);•
...
                }•
•
                g_free (ibus_path);•
        }•

So I guess what happened is ibus got installed when it wasn't previously.

How did you set up a compose key? tweak tool? xorg.conf ?

anyway presumably, ibus should behave transparently here, so moving to ibus.

> How did you set up a compose key? tweak tool? xorg.conf ?

I think it came directly from the Region&Language settings, with Keyboard=English(US and Euro on 5). But it may well be that it was setup a 
long time before through gnome-tweaks (which did not have that name, I think). Because I keep my (NFS) home directory over OS upgraades, the setting may have been conserved in this way.

Anyway, what I observed was rather curious, because I had several xterms running, which took into account the Compose Key, for several months. But after a recent reboot, the first xterm opened afterwards seemed to not even receive the keyhit for the Compose.

At first, "Japanese (Kanji)" AKA ibus-kkc does not enable Compose and you need to use "English (US)".

Seems /usr/libexec/ibus-x11 failed to open IMOpenIM() in RHEL 7 because gdm's ibus-x11 open IMOpenIM().

Dirk Hoffmann:

You could see the two PIDs of ibus-x11, one is owned by gdm and another is owned by your account.

1. If you kill the PID of gdm's ibus-x11, ibus-x11 won't restart.
2. And if you kill the PID of your account's ibus-x11, it restart.
3. And you could run xterm again and enable the compose typing?

Thanks for your analysis, Fujiwara-san.

These are the ibus-x11 instances:

gdm      15791     1  0 Mar07 ?        00:00:11 /usr/libexec/ibus-x11 --kill-daemon
hoffmann 15970     1  0 Mar07 ?        00:00:00 /usr/libexec/ibus-x11 --kill-daemon

However, I am not sure what you want me to test here:

1. If you kill the PID of gdm's ibus-x11, ibus-x11 won't restart.
2. And if you kill the PID of your account's ibus-x11, it restart.
3. And you could run xterm again and enable the compose typing?


So I started with 2., as it is the least invasive. Indeed, after killing 15970, I have:

gdm      15791     1  0 Mar07 ?        00:00:11 /usr/libexec/ibus-x11 --kill-daemon
hoffmann 24488     1  0 11:37 ?        00:00:00 /usr/libexec/ibus-x11 --kill-daemon

And no improvement with a new "xterm".


Then I killed 15791. It did not restart. And "xterm" correctly works with accents.


I also tried to kill again 24488, which reappeared. And "xterm" continues to work correctly, even with XMODIFIERS=@im=ibus.


Is that what you wanted me to test?

So the conclusion is that there is a pending ibus-x11 from the gdm, which needs to be reaped at session start?

(In reply to Dirk Hoffmann from comment #6)
> And no improvement with a new "xterm".

Because you didn't kill the PID of gdm in step 1.

> Then I killed 15791. It did not restart. And "xterm" correctly works with
> accents.

OK, I assume your compose key works fine with the workaround.

> So the conclusion is that there is a pending ibus-x11 from the gdm, which
> needs to be reaped at session start?

gdm's ibus-x11 always terminates and the problem does not happen in Fedora and I will backport the fix to RHEL 7 and ask you the test again.

Thank you for the report.

The problem is that input method does not work in X11 applications besides compose key due to gdm's ibus-x11.
I change the bug title.

Seems the ibus latest patches for x11 has been applied to RHEL 7.
I looked at the double ibus-x11 in Fedora 27 but I cannot reproduce this problem.
I need to investigate why  /usr/libexec/ibus-x11 failed to open IMOpenIM() in RHEL 7.

Dirk, you are still on 7.4, right?  Would be better if you could test (upgrade to) 7.6.

Sorry, I must have be mistaken when I wrote 7.4. I just checked, the machine is on 7.6 and certainly noone installed it since the beginning of this month. 

(The machine is third-party managed, and I am right now not in front of it for a couple of days.)

I understood that there should be patches available for me to test. However my system seems to be up to date with respect to the repo:

marmont:~[1010] sudo yum upgrade *x11*
Loaded plugins: langpacks
No packages marked for update
marmont:~[1010] sudo yum upgrade *ibus*
Loaded plugins: langpacks
No packages marked for update

Should I enable a particular repository?

Since I can reproduce your problem, I think you have no action item at the moment.
Seems there is no difference of ibus-x11 between the latest RHEL 7 and Fedora so I guess the evaluation might take time.
Since the problem has not been reproduced in Fedora, it might be a RHEL 7 specific issue likes security but not sure at the moment.
I think the above workaround would be nice or you could set `XMODIFIERS=@im=none`.

Thanks much.

Test result for RHEL7.7 Alpha compose :

ibus-emoji candidate window is not appearing in gedit and other application on X11 session.
Version of the component : ibus-1.5.17-4.el7

Now the dead line is coming for RHEL 7.8 and I accept this bug.

Currently ibus-x11 detects XIOError and assume the error as the
desktop session is closed and ibus-x11 calls Exit D-Bus method to
exit ibus-daemon. But ibus-x11 detects XError in RHEL 7.7 before
XIOError and GTK does not allow to bind XError by applications and
GTK calls gdk_x_error() with XError.

E.g. GdkX11Screen calls XGetSelectionOwner() for "_XSETTINGS_S?"
atoms during the logout but the selection owner already becomes
NULL and the NULL window causes XError with
gdk_x11_window_foreign_new_for_display().

Since ibus-x11 exits with XError before XIOError, gnome-shell
can detects the exit of ibus-daemon a little earlier and
gnome-shell restarts ibus-daemon but gnome-shell dies soon.
Then gnome-shell dies but ibus-daemon is alive, it's a problem.
Because it causes double ibus-x11 of GDM and a login user
and double XSetSelectionOwner() is not allowed for the unique
"ibus" atom and the user cannot use XIM but not GtkIMModule.

Probably we could fix the ibus process problem if we would fix
XError about the X selection owner or stop to restart ibus-daemon
in gonme-shell when the session is logging out.
Maybe using SessionManager.LogoutRemote() or
global.screen.get_display().get_xdisplay()
But I assume thereare other scenarios to causes the problem.

And I decided ibus-daemon always exits with the parent's death here
to avoid unexpected ibus restarts during the logout.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1017