fcitx resets Plasma keyboard layout on Wayland without being enabled as VK

[jpetso]

Summary

fcitx will autostart on Plasma login. This makes sense on X11, but not on Plasma Wayland where fcitx needs to be enabled as Virtual Keyboard in System Settings first. There is a pop-up on startup to warn the user about this, although there is no straightforward way for the user to disable autostart (the "Active By Default" option does not affect autostart behavior).

When fcitx starts, it resets any keyboard layout settings that the user may have set up previously. This is a problem, because:

1. fcitx does not support all keyboard layouts that Plasma supports. For example, I use the "EurKEY (US)" layout and it does not exist in fcitx.
2. The user experience is poor for users that don't need input methods. As a result, most distributions will not install fcitx5 by default. I would like fcitx5 to be installed by default on many distros.

Steps to Reproduce

On Arch Linux, install fcitx5, fcitx5-configtool, fcitx5-hangul and fcitx5-qt. Then restart the Plasma/Wayland session without touching any configuration.

Expected Behavior

Imho a good way forward would be for fcitx to remain disabled until the user manually enables it. In a Plasma/Wayland session, there is an explicit trigger for this: when fcitx gets started by the compositor (X-KDE-Wayland-VirtualKeyboard=true) then fcitx should apply its settings.

Ideally, when it quits, fcitx should restore the previous keyboard settings that it has overwritten while it was active.

In the long run, it would be great if there is only one language input config module in System Settings, whose settings (incl. keyboard layout) are shared by Plasma and fcitx. I'm curious if you have thoughts on how to make this happen.

Output of fcitx5-diagnose command

Output of fcitx5-diagnose command

System Info:

1. uname -a:

   Linux quint 6.12.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 2025 02:26:57 +0000 x86_64 GNU/Linux
   

2. lsb_release -a:

   LSB Version:    n/a
   Distributor ID: Arch
   Description:    Arch Linux
   Release:        rolling
   Codename:       n/a
   

3. lsb_release -d:

   Description:    Arch Linux
   

4. /etc/lsb-release:

   DISTRIB_ID="Arch"
   DISTRIB_RELEASE="rolling"
   DISTRIB_DESCRIPTION="Arch Linux"
   

5. /etc/os-release:

   NAME="Arch Linux"
   PRETTY_NAME="Arch Linux"
   ID=arch
   BUILD_ID=rolling
   ANSI_COLOR="38;2;23;147;209"
   HOME_URL="https://archlinux.org/"
   DOCUMENTATION_URL="https://wiki.archlinux.org/"
   SUPPORT_URL="https://bbs.archlinux.org/"
   BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
   PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
   LOGO=archlinux-logo
   

6. Desktop Environment:

   Desktop environment is kde.

7. XDG SESSION TYPE:

   XDG_SESSION_TYPE='wayland'
   

8. Bash Version:

   BASH_VERSION='5.2.37(1)-release'
   

Environment:

1. DISPLAY:

   DISPLAY=':1'
   
   
   WAYLAND_DISPLAY='wayland-0'
   

2. Keyboard Layout:

   1. setxkbmap:

      WARNING: Running setxkbmap against an Xwayland server
      xkb_keymap {
          xkb_keycodes  { include "evdev+aliases(qwerty)" };
          xkb_types     { include "complete"      };
          xkb_compat    { include "complete"      };
          xkb_symbols   { include "pc+us+inet(evdev)"     };
          xkb_geometry  { include "pc(pc105)"     };
      };
      

   2. xprop:

      _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""
      

3. Locale:

   1. All locales:

      C
      C.utf8
      de_AT.utf8
      en_CA.utf8
      en_US.utf8
      POSIX
      

   2. Current locale:

      LANG=en_US.UTF-8
      LC_CTYPE="en_US.UTF-8"
      LC_NUMERIC="en_US.UTF-8"
      LC_TIME=en_CA.UTF-8
      LC_COLLATE="en_US.UTF-8"
      LC_MONETARY="en_US.UTF-8"
      LC_MESSAGES="en_US.UTF-8"
      LC_PAPER="en_US.UTF-8"
      LC_NAME="en_US.UTF-8"
      LC_ADDRESS="en_US.UTF-8"
      LC_TELEPHONE="en_US.UTF-8"
      LC_MEASUREMENT=en_CA.UTF-8
      LC_IDENTIFICATION="en_US.UTF-8"
      LC_ALL=
      

4. Directories:

   1. Home:

      /home/kpetso
      

   2. ${XDG_CONFIG_HOME}:

      Environment variable XDG_CONFIG_HOME is not set.

      Current value of XDG_CONFIG_HOME is ~/.config (/home/kpetso/.config).

   3. Fcitx5 Settings Directory:

      Current fcitx5 settings directory is ~/.config/fcitx5 (/home/kpetso/.config/fcitx5).

5. Current user:

   The script is run as kpetso (2001).

Fcitx State:

1. executable:

   Found fcitx5 at /usr/bin/fcitx5.

2. version:

   Fcitx version: 5.1.11

3. process:

   Found 2 fcitx5 processes:

    285313 fcitx5
    295685 fcitx5
   

4. fcitx5-remote:

   fcitx5-remote works properly.

5. DBus interface:

   Using dbus-send to check dbus.

   Owner of DBus name org.fcitx.Fcitx5 is :1.51.

   PID of DBus name org.fcitx.Fcitx5 owner is 285313.

   Debug information from dbus:

      Group [wayland:] has 1 InputContext(s)
     IC [483ad52f794a4f3dbcf9f52cdd956be2] program: frontend:ibus cap:12 focus:0
   Group [x11::1] has 0 InputContext(s)
   Input Context without group
   

Fcitx Configure UI:

1. Config Tool Wrapper:

   Found fcitx5-configtool at /usr/bin/fcitx5-configtool.

2. Config GUI for qt:

   Found fcitx5-config-qt at /usr/bin/fcitx5-config-qt.

3. Config GUI for kde:

   kcmshell5 not found.

Frontends setup:

The environment variable checked by this script only shows the environment under current shell. It is still possible that you did not set the environment to the whole graphic desktop session. You may inspect the actual environment variable of a certain process by using xargs -0 -L1 /proc/$PID/environ for a certain process that you find not working.

Xim:

1. ${XMODIFIERS}:

   XMODIFIERS is not set

   Please set environment variable XMODIFIERS to "@im=fcitx" using the tool your distribution provides or add export XMODIFIERS=@im=fcitx to your ~/.xprofile. See Input Method Related Environment Variables: XMODIFIERS.
   Xim Server Name from Environment variable is fcitx.

2. XIM_SERVERS on root window:

   Xim server name is the same with that set in the environment variable.

Qt:

1. qt4 - ${QT4_IM_MODULE}:

   Please set environment variable QT_IM_MODULE to "fcitx" using the tool your distribution provides or add export QT_IM_MODULE=fcitx to your ~/.xprofile. See Input Method Related Environment Variables: QT_IM_MODULE.

   fcitx5-qt4-immodule-probing not found.

2. qt5 - ${QT_IM_MODULE}:

   Please set environment variable QT_IM_MODULE to "fcitx" using the tool your distribution provides or add export QT_IM_MODULE=fcitx to your ~/.xprofile. See Input Method Related Environment Variables: QT_IM_MODULE.

   It is OK to use qt5 built-in Wayland im module if your compositor fully supports text-input protocol used by qt5.

   Using fcitx5-qt5-immodule-probing to check the actual im module to be used under current environment:

   QT_QPA_PLATFORM=wayland
   QT_IM_MODULE=
   IM_MODULE_CLASSNAME=QtWaylandClient::QWaylandInputContext
   

3. qt6 - ${QT_IM_MODULE}:

   Please set environment variable QT_IM_MODULE to "fcitx" using the tool your distribution provides or add export QT_IM_MODULE=fcitx to your ~/.xprofile. See Input Method Related Environment Variables: QT_IM_MODULE.

   It is OK to use qt6 built-in Wayland im module if your compositor fully supports text-input protocol used by qt6.

   Using fcitx5-qt6-immodule-probing to check the actual im module to be used under current environment:

   QT_QPA_PLATFORM=wayland
   QT_IM_MODULE=
   IM_MODULE_CLASSNAME=QtWaylandClient::QWaylandInputContext
   

4. Qt IM module files:

   Found fcitx5 qt5 module: /usr/lib/fcitx5/qt5/libfcitx-quickphrase-editor5.so.
   Found fcitx5 qt6 module: /usr/lib/fcitx5/qt6/libfcitx-quickphrase-editor5.so.
   Found fcitx5 im module for qt: /usr/lib/qt/plugins/platforminputcontexts/libfcitx5platforminputcontextplugin.so.
   Found unknown fcitx qt module: /usr/lib/qt6/plugins/plasma/kcms/systemsettings/kcm_fcitx5.so.
   Found fcitx5 im module for qt6: /usr/lib/qt6/plugins/platforminputcontexts/libfcitx5platforminputcontextplugin.so.

   Following error may not be accurate because guessing Qt version from path depends on how your distribution packages Qt. It is not a critical error if you do not use any Qt application with certain version of Qt or you are using text-input support by Qt under Wayland.
   Cannot find fcitx5 input method module for Qt4.

Gtk:

1. gtk - ${GTK_IM_MODULE}:

   Please set environment variable GTK_IM_MODULE to "fcitx" using the tool your distribution provides or add export GTK_IM_MODULE=fcitx to your ~/.xprofile. See Input Method Related Environment Variables: GTK_IM_MODULE.

   It is OK to use gtk built-in Wayland im module if your compositor fully supports text-input protocol used by gtk.

   fcitx5-gtk2-immodule-probing not found.

   fcitx5-gtk3-immodule-probing not found.

   fcitx5-gtk4-immodule-probing not found.

2. gtk-query-immodules:

   1. gtk 2:

      Found gtk-query-immodules for gtk 2.24.33 at /usr/bin/gtk-query-immodules-2.0.
      Version Line:

      # Created by /usr/bin/gtk-query-immodules-2.0 from gtk+-2.24.33
      

      Failed to find fcitx5 in the output of /usr/bin/gtk-query-immodules-2.0

      Cannot find fcitx5 im module for gtk 2.

   2. gtk 3:

      Found gtk-query-immodules for gtk 3.24.48 at /usr/bin/gtk-query-immodules-3.0.
      Version Line:

      # Created by /usr/bin/gtk-query-immodules-3.0 from gtk+-3.24.48
      

      Failed to find fcitx5 in the output of /usr/bin/gtk-query-immodules-3.0

      Cannot find fcitx5 im module for gtk 3.

3. Gtk IM module cache:

   1. gtk 2:

      Found immodules cache for gtk 2.24.33 at /usr/lib/gtk-2.0/2.10.0/immodules.cache.
      Version Line:

      # Created by /usr/bin/gtk-query-immodules-2.0 from gtk+-2.24.33
      

      Failed to find fcitx5 in immodule cache at /usr/lib/gtk-2.0/2.10.0/immodules.cache

      Cannot find fcitx5 im module for gtk 2 in cache.

   2. gtk 3:

      Found immodules cache for gtk 3.24.48 at /usr/lib/gtk-3.0/3.0.0/immodules.cache.
      Version Line:

      # Created by /usr/bin/gtk-query-immodules-3.0 from gtk+-3.24.48
      

      Failed to find fcitx5 in immodule cache at /usr/lib/gtk-3.0/3.0.0/immodules.cache

      Cannot find fcitx5 im module for gtk 3 in cache.

4. Gtk IM module files:

   1. gtk 2:

      All found Gtk 2 immodule files exist.

   2. gtk 3:

      All found Gtk 3 immodule files exist.

   3. gtk 4:

      All found Gtk 4 immodule files exist.

Configuration:

Fcitx Addons:

1. Addon Config Dir:

   Found fcitx5 addon config directory: /usr/share/fcitx5/addon.

2. Addon List:

   1. Found 21 enabled addons:

      Classic User Interface 5.1.11
      Clipboard 5.1.11
      DBus 5.1.11
      DBus Frontend 5.1.11
      Emoji 5.1.11
      Fcitx4 Frontend 5.1.11
      Hangul 5.1.5
      IBus Frontend 5.1.11
      Input method selector 5.1.11
      Keyboard 5.1.11
      KDE Input Method Panel 5.1.11
      Status Notifier 5.1.11
      Notification 5.1.11
      Quick Phrase 5.1.11
      Spell 5.1.11
      Unicode 5.1.11
      DBus Virtual Keyboard 5.1.11
      Wayland 5.1.11
      Wayland Input method frontend 5.1.11
      XCB 5.1.11
      X Input Method Frontend 5.1.11
      

   2. Found 0 disabled addons:

3. Addon Libraries:

   All libraries for all addons are found.

4. User Interface:

   Found 3 enabled user interface addons:

   Classic User Interface
   KDE Input Method Panel
   DBus Virtual Keyboard
   

Input Methods:

1. /home/kpetso/.config/fcitx5/profile:

   [Groups/0]
   # Group Name
   Name=Default
   # Layout
   Default Layout=us
   # Default Input Method
   DefaultIM=keyboard-us
   
   [Groups/0/Items/0]
   # Name
   Name=keyboard-us
   # Layout
   Layout=
   
   [GroupOrder]
   0=Default
   

Log:

1. date:

   Thu 06 Feb 2025 02:20:57 PM EST
   

2. /home/kpetso/.config/fcitx5/crash.log:

   /home/kpetso/.config/fcitx5/crash.log not found.

Warning: the output of fcitx5-diagnose contains sensitive information, including the distribution name, kernel version, name of currently running programs, etc.

Though such information can be helpful to developers for diagnostic purpose, please double check and remove as necessary before posting it online publicly.

[wengxt]

No, while kcm's called "virtual keyboard", it is actually the wayland input method launched by kwin.

If you want use the onscren keyboard, you should try to use one that integrates with fcitx.

https://gitee.com/openkylin/kylin-virtual-keyboard

https://www.csslayer.info/wordpress/fcitx-dev/%E6%BC%94%E7%A4%BA%E4%B8%80%E4%B8%8B%E5%92%8C-openkylin-%E5%90%88%E4%BD%9C%E5%BC%80%E5%8F%91%E7%9A%84%E8%99%9A%E6%8B%9F%E9%94%AE%E7%9B%98/

[jpetso]

Reopening because I think there is a misunderstanding. (Edit: Whoops, I don't have permissions to reopen. Oh well.)

I would like to:

• have fcitx installed,
• not use fcitx most of the time (except when I explicitly enable it),
• and keep my Plasma keyboard layout settings as I configured it.

This would be a very common setup for users outside of Asia.

[wengxt]

Oh, sorry I thought you mean plasma keyboard.

Then answer is still no, you can simply use fcitx to manage plasma layout.

You simply need to add multiple input method groups and assign them your layout separately. (super space by default is the group switching)

If you only use layout for text typing, you can also use one group.

Let me know if you need more help on how to set it up.

[wengxt]

There is also another option to ask fcitx to not touch kde's layout, you might want to use that if you are not satisfied with the way that fcitx manages it.

configure addon -> wayland

Allow Overriding System XKB Settings uncheck

[jpetso]

Thank you for the pointers.

For context: I am a Plasma developer. My main interest is to improve the user experience on a default Plasma installation.

In the context of input methods, we have several groups of users:

1. Users that don't need an input method at all. They should be able to use regular Plasma settings without learning about fcitx at all.
2. Users that regularly need an input method. They should be able to use fcitx out of the box, pre-installed, only set up Input Method in System Settings and then they're good to go.
3. Users that don't usually need an input method, but sometimes have a use for it, e.g. when learning Chinese. They should be able to turn fcitx on and off without losing settings permanently.

If we want to ship fcitx by default, it needs to work for all of these groups. I would like to find a path forward where the same distro setup can make all users happy.

[wengxt]

Well, the only sane way to me is to integrate fcitx into plasma keyboard layout management, like how input method and keyboard layout are managed uniformly on Windows or Mac or Android. It's only on linux(or "open source" desktop) that you have so many frameworks that is interchangeable and optional and work as independent project.

Input method, or keyboard layout are just same thing (conceptually) to me. And they should have a uniformed UI to manage.

[wengxt]

I'm not sure I could "claim" myself as a Plasma developer too, but I do maintain an input method plasmoid in plasma-desktop and contribute a lot in kwin's wayland input method implementation.

If you're interested in this topic may be also check one of my old post and this is basically how fcitx5 itself manages the layout today: https://www.csslayer.info/wordpress/linux/rfc-a-new-solution-to-input-method-keyboard-layout/

Words below are very personal:

Though, I commonly try to avoid convincing people to do tight integration on fcitx and plasma even though I think it is the right way to go. I also write my KCM for fcitx as a "third party" plugin to Plasma.

When GNOME choose to integrate ibus in to their system settings back in 2012 and Redhat, just hiring people to manage ibus. I had a long argument on gnome's maillist and I almost totally give up on such topic from that day because it makes me feel so exhausted without doing any real things. I even consider why I even keep using Linux or evolving any open source projects.

It's KDE that still makes me feel open source is still open so I didn't give up and continue all these things till today.

At the same time, I also try to keep my attitudes open to other IM frameworks even though I want it so much to make Plasma to native fcitx integration and I don't really want to argue with people. So in the end I just did some integration from what third party project "can" do.

If you're interested on this topic/project (integrate fcitx into plasma) we can also chat on IRC/Matrix.

[jpetso]

It's only on linux(or "open source" desktop) that you have so many frameworks that is interchangeable and optional and work as independent project.

Input method, or keyboard layout are just same thing (conceptually) to me. And they should have a uniformed UI to manage.

I absolutely agree with this goal! And other KDE developers do as well. However, we're still struggling to find the time/resources to refactor the existing infrastructure in a way that respects user choices, deals with the existing code, and works with the Wayland protocol mess. You know better than I that this is a large space and massive amount of work.

At Akademy 2024, we had discussions about how to move forward and were planning grant proposals. Eike Hein, in particular, taught me a lot about the history of input methods on Linux and related to KDE. So far we have not applied for funding in this area, but input handling is now an official KDE Goal so my hope is that one of us can start putting more effort into input methods on Plasma between H3 2025 and H3 2026. (Note: in addition to input methods, the input handling goal also includes mouse & touchpad, drawing tablets, game controllers, and a few other topics.)

I understand that it makes sense for you to keep fcitx a separate project; frankly, it's already a very large effort and tight integration requires as much coordination as it requires actual code. I think it would be a great outcome if we can change Plasma so that fcitx can remain separate and optional, but shares a unified "input language" settings UI with upstream Plasma components.

We created a Matrix channel #kde-input:kde.org after input handling was elected as KDE Goal in September. If you're also on Matrix, feel free to drop by and join the discussion! I can't promise how much work we'll get done in which time frame, but hopefully we can figure out a long-term plan and then chip away at it piece by piece.