[Linux] Blender always uses the first configured keyboard layout in some situations #115160

New Issue

Eugene-Kuznetsov · 2023-11-20T04:55:09+01:00

Eugene-Kuznetsov commented

2023-11-20 04:55:09 +01:00

I'm observing this on Ubuntu 22.04/Gnome 42.9/Wayland, and I've been able to reproduce this with 3.6.5, 4.0.0, and head of trunk. It does not occur in Windows. There may be some dependency on X11 configuration or packages, because I don't recall seeing this previously.

This bug occurs if the user has more than one keyboard layout configured.

For example, suppose the user has 'English (US)' aka 'QWERTY', 'English (Dvorak)', and 'Russian' layouts.

In the text editor, hotkeys Ctrl-C and Ctrl-V always use the first layout. That is, if it the first layout is 'English (QWERTY)', to copy/paste text, I need to press Ctrl + 3rd and 4th key in the bottom letter row, not counting modifier keys (the ones with 'C' and V' on the QWERTY keyboard), even if a different layout is active. If the first layout is 'English (Dvorak)', 'paste' is Ctrl + second key from the right in the bottom row. If the first layout is 'Russian', there's no way to copy/paste with hotkeys at all, because there's no letter 'V' in Russian.
The correct behavior (which is what every other app does) is to respect the layout: text paste is 'Ctrl' + whichever key maps to 'V' in the active layout.
In the 3D editor, standard edit keys (G, R for 'rotate', S for 'scale') also always use the first layout. If it is 'English (US)', I can drag objects by clicking on them and hitting 'G' (fifth key in the middle row), even if the active layout is different.

Steps to reproduce:

In Ubuntu settings, set up two keyboard layouts, e.g. English (US) and English (Dvorak), with English (US) on top .
Open a blank blend file. Go to 'Scripting' and create a new text file. Make sure that 'English (Dvorak)' is active. Hit the first five keys in the bottom row. You will see ';qjkx'.
Select everything, hit Ctrl+C, clear selection, move cursor to the end, hit Ctrl+V (4th key, bottom row). Observe that a paste operation has been performed.
Switch layout to 'English (US)'. Click inside the text editor and hit the same key combo. Observe that a paste operation has been performed again.

I'm observing this on Ubuntu 22.04/Gnome 42.9/Wayland, and I've been able to reproduce this with 3.6.5, 4.0.0, and head of trunk. It does not occur in Windows. There may be some dependency on X11 configuration or packages, because I don't recall seeing this previously. This bug occurs if the user has more than one keyboard layout configured. For example, suppose the user has 'English (US)' aka 'QWERTY', 'English (Dvorak)', and 'Russian' layouts. 1. In the text editor, hotkeys Ctrl-C and Ctrl-V always use the first layout. That is, if it the first layout is 'English (QWERTY)', to copy/paste text, I need to press Ctrl + 3rd and 4th key in the bottom letter row, not counting modifier keys (the ones with 'C' and V' on the QWERTY keyboard), even if a different layout is active. If the first layout is 'English (Dvorak)', 'paste' is Ctrl + second key from the right in the bottom row. If the first layout is 'Russian', there's no way to copy/paste with hotkeys at all, because there's no letter 'V' in Russian. The correct behavior (which is what every other app does) is to respect the layout: text paste is 'Ctrl' + whichever key maps to 'V' in the active layout. 2. In the 3D editor, standard edit keys (G, R for 'rotate', S for 'scale') also always use the first layout. If it is 'English (US)', I can drag objects by clicking on them and hitting 'G' (fifth key in the middle row), even if the active layout is different. Steps to reproduce: * In Ubuntu settings, set up two keyboard layouts, e.g. English (US) and English (Dvorak), with English (US) on top . * Open a blank blend file. Go to 'Scripting' and create a new text file. Make sure that 'English (Dvorak)' is active. Hit the first five keys in the bottom row. You will see ';qjkx'. * Select everything, hit Ctrl+C, clear selection, move cursor to the end, hit Ctrl+V (4th key, bottom row). Observe that a paste operation has been performed. * Switch layout to 'English (US)'. Click inside the text editor and hit the same key combo. Observe that a paste operation has been performed again.

Eugene-Kuznetsov added the

labels 2023-11-20 04:55:10 +01:00

Eugene-Kuznetsov commented

2023-11-20 06:58:18 +01:00

I did some tracing to understand what is going on.

I go into the text editor and hit the physical key with 'C' on it.

keyboard_handle_key (c433f6666a/intern/ghost/intern/GHOST_SystemWayland.cc (L4177)) is called with 'key' containing 46 (the code for the third letter in the bottom row).

xkb_state_key_get_one_sym_without_modifiers is called to convert it into a xkb keysym. An empty xkb state used to do the conversion (line 4074), and information about the active layout is part of this xkb state. So, it always returns the keysym corresponding to the first (default) layout. This returned keysym is used for hotkey mapping.

Later on, there's a separate call to xkb_compose_state_feed_and_get_utf8, which does take the layout into consideration, and its output is used when typing, which is why active layout is respected during normal typing.

The following diff appears to resolve the bug for me:

index cee553a46e8..4bcc54b9800 100644
--- a/intern/ghost/intern/GHOST_SystemWayland.cc
+++ b/intern/ghost/intern/GHOST_SystemWayland.cc
@@ -4357,6 +4357,7 @@ static void keyboard_handle_modifiers(void *data,
 
   GWL_Seat *seat = static_cast<GWL_Seat *>(data);
   xkb_state_update_mask(seat->xkb.state, mods_depressed, mods_latched, mods_locked, 0, 0, group);
+  xkb_state_update_mask(seat->xkb.state_empty, 0, 0, 0, 0, 0, group);
 
   /* A modifier changed so reset the timer,
    * see comment in #keyboard_handle_key regarding this behavior. */

I did some tracing to understand what is going on. I go into the text editor and hit the physical key with 'C' on it. keyboard_handle_key (https://projects.blender.org/blender/blender/src/commit/c433f6666a9038cbe4d57cb504a312d61e9524c9/intern/ghost/intern/GHOST_SystemWayland.cc#L4177) is called with 'key' containing 46 (the code for the third letter in the bottom row). xkb_state_key_get_one_sym_without_modifiers is called to convert it into a xkb keysym. An empty xkb state used to do the conversion (line 4074), and information about the active layout is part of this xkb state. So, it always returns the keysym corresponding to the first (default) layout. This returned keysym is used for hotkey mapping. Later on, there's a separate call to xkb_compose_state_feed_and_get_utf8, which does take the layout into consideration, and its output is used when typing, which is why active layout is respected during normal typing. The following diff appears to resolve the bug for me: ```diff --git a/intern/ghost/intern/GHOST_SystemWayland.cc b/intern/ghost/intern/GHOST_SystemWayland.cc index cee553a46e8..4bcc54b9800 100644 --- a/intern/ghost/intern/GHOST_SystemWayland.cc +++ b/intern/ghost/intern/GHOST_SystemWayland.cc @@ -4357,6 +4357,7 @@ static void keyboard_handle_modifiers(void *data, GWL_Seat *seat = static_cast<GWL_Seat *>(data); xkb_state_update_mask(seat->xkb.state, mods_depressed, mods_latched, mods_locked, 0, 0, group); + xkb_state_update_mask(seat->xkb.state_empty, 0, 0, 0, 0, 0, group); /* A modifier changed so reset the timer, * see comment in #keyboard_handle_key regarding this behavior. */ ```

~~Eugene-Kuznetsov referenced this issue 2023-11-20 07:10:00 +01:00~~

Fix #115160: Using active keyboard layout for hotkeys in X11/Wayland #115161

Iliya Katushenock referenced a pull request that will close this issue

2023-11-20 11:25:16 +01:00

Fix #115160: Using active keyboard layout for hotkeys in X11/Wayland #115161

Pratik Borhade commented

2023-11-20 12:36:07 +01:00

Hi, confirming since we already have a potential fix, thanks for that.

Pratik Borhade added

Module

User Interface