Bug 488268 - Alternative global shortcut to change keyboard layout is triggered twice when using modifier-only shortcuts
Summary: Alternative global shortcut to change keyboard layout is triggered twice when...
Status: RESOLVED FIXED
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 487276 488280 490226 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-06-09 20:59 UTC by ratijas
Modified: 2024-08-23 23:55 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0
Sentry Crash Report:


Attachments
Keyboard KCM - Layouts page (83.77 KB, image/png)
2024-06-09 20:59 UTC, ratijas
Details
Keyboard switching not working in lockscreen (2.87 MB, video/x-matroska)
2024-07-18 07:46 UTC, elydgolden
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ratijas 2024-06-09 20:59:06 UTC
Created attachment 170300 [details]
Keyboard KCM - Layouts page

SUMMARY

On the lock screen the Shortcut for Switching Layout (as it is called in the Keyboard KCM) does not actually switch any layouts, despite making an OSD appear. Sometimes you can briefly see for a frame or two that the layout has been changed, before it changes back, hinting at double activation of the shortcut. On an unlocked desktop the shortcut works fine.

Note that the kscreenlocker greeter process at least on X11 implements a completely custom keyboard grab, including fetching a whitelist of global shortcuts and handling them in-process itself.

STEPS TO REPRODUCE
1. Use X11 session.
2. Set up an Alternative shortcut in the Keyboard KCM, for example, to Meta+Space (fairly popular and my personal favorite); add some layouts so that you have more than one.
3. Lock the screen.
4. Try switching the keyboard layout using the Alternative shortcut.

OBSERVED RESULT
The keyboard layout does not change; OSD appears showing the name of the current layout.

EXPECTED RESULT
Keyboard layout should change.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: git-master
KDE Frameworks Version: git-master
Qt Version: 6.7.1
Kernel Version: 6.9.3-arch1-1 (64-bit)
Graphics Platform: X11
Comment 1 TraceyC 2024-07-18 00:05:25 UTC
*** Bug 487276 has been marked as a duplicate of this bug. ***
Comment 2 TraceyC 2024-07-18 00:05:59 UTC
From https://bugs.kde.org/show_bug.cgi?id=487276

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.
Comment 3 TraceyC 2024-07-18 00:08:41 UTC
*** Bug 488280 has been marked as a duplicate of this bug. ***
Comment 4 TraceyC 2024-07-18 00:09:49 UTC
*** Bug 490226 has been marked as a duplicate of this bug. ***
Comment 5 elydgolden 2024-07-18 07:45:50 UTC
Can confirm on openSUSE Tumbleweed, so it's definitely a problem on the latest Plasma as well. 

In addition, the "Last Used" shortcut does not work properly. It might work after pressing the alternative global switching shortcut, but it still tries to press a key into the password field in that case (see the duplicate issue 490226)
Comment 6 elydgolden 2024-07-18 07:46:52 UTC
Created attachment 171751 [details]
Keyboard switching not working in lockscreen
Comment 7 fanzhuyifan 2024-08-04 19:33:33 UTC
(In reply to TraceyC from comment #2)

> 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.

So I think that this is an issue some what different from the one originally reported here. The originally reported issue was about the Alternate Layout switching shortcut defined in plasma. Since that is defined in plasma, at least theoretically we could whitelist that shortcut by default in lockscreen. However, fcitx is a 3rd party program, and to whitelist its shortcuts, we would need a different method -- expose some method to whitelist shortcuts from certain 3rd party applications in lock screen. The security risks would also be different -- in the second case we have to trust the 3rd party program to not compromise the login security.
Comment 8 fanzhuyifan 2024-08-05 17:15:57 UTC
By creating 3 layouts, I can confirm that the shortcut is triggered twice. This happens independent of the number of monitors. (I tested on 1 and 2)

As of git master, this only happens with modifier-only shortcuts.
Comment 9 fanzhuyifan 2024-08-05 17:17:13 UTC
I created BUG 491315 to keep track of the general issue of modifier-only shortcuts triggering when input is grabbed.
Comment 10 Bug Janitor Service 2024-08-09 01:58:25 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/60
Comment 11 fanzhuyifan 2024-08-20 21:39:23 UTC
Git commit d5be3e16b9e2921c88cc8e0181a5b1f2c13ad761 by Yifan Zhu.
Committed on 09/08/2024 at 01:50.
Pushed by fanzhuyifan into branch 'master'.

plugins/xcb: skip xrecord events when keyboard is grabbed

Otherwise modifier-only shortcuts still trigger when keyboard is grabbed
by some other client, e.g. during shortcut assignment and in lockscreen.

Keep track of keyboard grab state by listening to grab/ungrab requests.

Test plan 1:
- Under x11, in system settings, assign Meta to some shortcut.
- Assign meta to another shortcut
- Verify that the old shortcut does not trigger

Test plan 2:
- Under x11, choose multiple keyboard layouts
- assign Alt+Shift as alternate layout switching shortcut
- lock screen
- press Alt+Shift
- Verify that the layout change OSD pops up, and typed password uses the
  new layout
- repeat the last two steps
Related: bug 491315

M  +16   -0    src/plugins/xcb/kglobalaccel_x11.cpp
M  +1    -0    src/plugins/xcb/kglobalaccel_x11.h

https://invent.kde.org/plasma/kglobalacceld/-/commit/d5be3e16b9e2921c88cc8e0181a5b1f2c13ad761