https://bugs.kde.org/show_bug.cgi?id=506095
gray-aids-sw...@duck.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gray-aids-sw...@duck.com
--- Comment #4 from gray-aids-sw...@duck.com ---
I encountered the same issue, so I conducted various experiments.
# Conclusion: **This is not an issue with fcitx5, Its caused by KWin's XWayland
support flow**.
There is some inconsistency in the XWayland support flow within KWin that is
causing the problem.
Wayland input works only when KWin directly launches and manages fcitx5.
In such cases, however, KWin does not properly support X11 input through the
usual methods.
But standaloon fcitx5 always supports and integrity with XWayland application.
# First, let me describe my environment:
1. Arch Linux (latest)
2. KDE Plasma 6.4.3
3. Wayland
4. xterm (for testing via XWayland)
5. fcitx5-mozc (Japanese input)
# Here are the experiments I conducted:
1. Attempted to input text in an XWayland application using the usual method.
This was completely non-functional. I was unable to input anything in xterm.
The fcitx5 candidate window appeared at the “top-left corner beyond all
displays,” and regardless of the method used to confirm the input, all attempts
failed.
2. Manually launched fcitx5 using `fcitx5 -r`
With this, I was able to input text in xterm via XWayland without any issues.
However, input via native Wayland applications became impossible.
In practice, this is the expected behavior, as KWin needs to launch fcitx5
itself to handle Wayland input properly.
# Conclusion
Ultimately, the conclusion is that **KWin is the root cause**.
However, since Fcitx5 launched via KWin is at least able to display the IME
switch indicator for XWayland applications, it appears that they are being
recognized.
It's not that KWin is poorly designed or anything; it's just that some part of
the mechanism isn't fitting together properly at the moment.
--
You are receiving this mail because:
You are watching all bug changes.
