Thank you for the report.
BTW, 1.5.19-13 is not on stable yet.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-3aa0fbffb4

It would be great if you could provide the reproducing steps. I'm try to reproduce this.

I don't know if its the same thing but recently on rawhide at random points the shell stops accepting keyboard input.
The log says something like
...
Jan 31 10:29:01 gnome-shell[10841]: Error processing key on IM: Timeout was reached
...
and input doesn't work until I switch to a vt and killall ibus-daemon, which fixes it until the next time it happens.

keyboard input has stopped for me  me as well, and the issue went away when I downgraded from ibus 1.5.19-12.fc29 to 1.5.19-11.fc29.  I'm US keyboard and I don't think I've ever configured any ibus settings.  My distro has been installed a long time ago and upgraded to fedora 29.

one thing I can say is that some keyboard controls work: (e.g. Alt-F2 to bring up the gnome-shell run command window).  

I don't notice any particular messages in journald at the time.

(In reply to Kenneth Topp from comment #3)
> keyboard input has stopped for me  me as well, and the issue went away when
> I downgraded from ibus 1.5.19-12.fc29 to 1.5.19-11.fc29.  I'm US keyboard
> and I don't think I've ever configured any ibus settings.

I guess you downgraded ibus 1.5.19-13.fc29 to 1.5.19-11.fc29 but not ibus 1.5.19-12.fc29.

I still cannot reproduce the problem.

I also have this when it just stops accepting input while typing and just repeats last entered character like it is pressed . Reboot solves it.

$ rpm -q ibus
ibus-1.5.19-13.fc29.x86_64

I also upgraded the Kernel at the same time as ibus to kernel-4.20.5-200.fc29.x86_64 (from testing)

I have yet to replicate the problem on kernel-4.20.4-200.fc29.x86_64

I've also run into this problem - the keyboard randomly stops responding to characters and is fixed by a reboot. Special keys (such as volume up/down) continue to work even when the keyboard appears to be unresponsive. I've downgraded from -13 to -12 and have yet to replicate the problem with the following installed:

ibus-gtk2-1.5.19-12.fc29.x86_64
ibus-setup-1.5.19-12.fc29.noarch
ibus-1.5.19-12.fc29.x86_64
ibus-wayland-1.5.19-12.fc29.x86_64
ibus-libs-1.5.19-12.fc29.x86_64
ibus-gtk3-1.5.19-12.fc29.x86_64

Changing the kernel version didnt make any difference (tested with 4.20.6-200 or 4.20.5-200, although I didnt go back to kernel 4.20.4-200).

I'm seeing this problem as well, under the MATE desktop.

Some seemingly-random amount of time after logging in, most windows stop accepting input.

Unfortunately, I don't know how to reproduce the issue reliably or consistently. I can't find any consistent trigger for the problem. Sometimes it happens while I'm typing; sometimes it happens when I'm not typing.

Downgrading the ibus packages back to 1.5.19-12.fc29 avoids the issue.

*** Bug 1671774 has been marked as a duplicate of this bug. ***

Thank you all.
Probably I can reproduce this issue now in a standalone machine but I could not in a VirtualBox VM.
Maybe pressing Shift key is needed.
Seems still mutex is conflict.

Problem exists on kernel-4.20.4-200.fc29.x86_64 also but took far longer to manifest.
Downgrade to 1.5.19-12.fc29 solves it.

(In reply to fujiwara from comment #4)
> (In reply to Kenneth Topp from comment #3)
> > keyboard input has stopped for me  me as well, and the issue went away when
> > I downgraded from ibus 1.5.19-12.fc29 to 1.5.19-11.fc29.  I'm US keyboard
> > and I don't think I've ever configured any ibus settings.
> 
> I guess you downgraded ibus 1.5.19-13.fc29 to 1.5.19-11.fc29 but not ibus
> 1.5.19-12.fc29.
> 
> I still cannot reproduce the problem.

Yes, I did have -13 installed.  

Something I just thought of is that I have two usb keyboards and a bluetooth keyboard attached.  It seems -13 was removed from the f29 yum channels.  I can attempt to reproduce without the extra keyboards and see if that has something to do with the issue.

Ken

when using -13 I got the stuck key or unresponsive keyboard within a few seconds of typing on both the builtin keyboard on the laptop and the external HP USB keyboard (when docked). Im now running ibus-1.5.19-12.fc29.x86_64.

(In reply to Alexander Lindqvist from comment #12)
> when using -13 I got the stuck key or unresponsive keyboard within a few
> seconds of typing on both the builtin keyboard on the laptop and the
> external HP USB keyboard (when docked). Im now running
> ibus-1.5.19-12.fc29.x86_64.

Laptop is HP Elitebook 745 G5

ibus-1.5.19-16.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3aa0fbffb4

ibus-1.5.19-16.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3aa0fbffb4

*** Bug 1673714 has been marked as a duplicate of this bug. ***

ibus-1.5.19-16.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Same error on my laptop (Lenovo X270) with Fedora 29 (upgraded from Fedora 28). I have the impression that this issue occurs only with the "internal" keyboard and not an usb keybord.

May 19 15:00:42 lp-20173009 journal[8464]: Error looking up permission: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for geolocation
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: The XKEYBOARD keymap compiler (xkbcomp) reports:
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: > Warning:          Unsupported maximum keycode 374, clipping.
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: >                   X11 cannot support keycodes above 255.
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: > Warning:          Unsupported high keycode 372 for name <I372> ignored
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: >                   X11 cannot support keycodes above 255.
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: >                   This warning only shows for the first high keycode.
May 19 15:00:42 lp-20173009 org.gnome.Shell.desktop[8464]: Errors from xkbcomp are not fatal to the X server

[patta@lp-20173009 ~]$ rpm -aq | grep ibus
ibus-m17n-1.4.1-1.fc29.x86_64
ibus-cangjie-2.4-13.fc29.noarch
ibus-rawcode-1.3.2-13.fc29.x86_64
libusbx-1.0.22-1.fc29.x86_64
ibus-gtk3-1.5.19-16.fc29.x86_64
ibus-libzhuyin-1.9.0-1.fc29.x86_64
ibus-libpinyin-1.11.0-1.fc29.x86_64
ibus-libs-1.5.19-16.fc29.x86_64
libusbx-1.0.22-1.fc29.i686
ibus-setup-1.5.19-16.fc29.noarch
ibus-cangjie-engine-cangjie-2.4-13.fc29.noarch
ibus-kkc-1.5.22-10.fc29.x86_64
python2-libuser-0.62-18.fc29.x86_64
libuser-0.62-18.fc29.x86_64
ibus-typing-booster-2.6.0-1.fc29.noarch
ibus-gtk2-1.5.19-16.fc29.x86_64
ibus-qt-1.3.3-20.fc29.x86_64
libusb-0.1.5-13.fc29.x86_64
ibus-hangul-1.5.1-2.fc29.x86_64
ibus-1.5.19-16.fc29.x86_64
libusal-1.1.11-40.fc29.x86_64
libusbmuxd-1.0.10-10.fc29.x86_64

@antoinep
I think your issue is not this bug.