***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY


STEPS TO REPRODUCE
1. (Using FCITX5 and IMPanel) define multiple input method groups/keyboards. For example Default, Chinese, Canadian, etc with appropriate keyboards and input methods in each category.

2. Ensure hotkeys are set to switch between keyboard layouts and input method groups.

3. After ensuring that multilingual input is working, trigger lock screen either by pressing hotkey or waiting for inactivity lock.

4. Note that there is no indicator to indicate current keyboard layout. Note also that the hotkey to switch language groups has no effect.

5. If you are now locked out because of not being able to enter  your password, switch VTs and execute "loginctl; loginctl unlock-session n" where n is the session number show in the output of loginctl.


OBSERVED RESULT
There is no way to enter password in the lock screen if it was triggered while a different keyboard is selected via FCITX/IMPanel

EXPECTED RESULT
At the very least, KScreenLocker should assert the system keyboard layout, since that is the one that would likely have been used to enter the login password. Ideally, full input-method support should be available in the login and lock screens.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian/KDE
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8

ADDITIONAL INFORMATION
This was not tried on the latest version of KDE, so if there is now input method support in the lock screen, please forgive me for wasting your time. :( However, as this bug exists on my main workstation which is the latest stable Debian, I felt it was worth making this report.

This was only tested with FCITX5/IMPanel, and not with any other input method framework, such as IBus nor KDE's built-in keyboard switcher.