Shift key handling on non US keyboard

I am using Manjaro linux on desktop with default config. This is tested on amd64 with HR keyboard, and arm64 with GB keyboard. When shift key is pressed as modifier, every key is handled twice. For instance pressing "l" moves map to the right by 10 (as is in default config), but pressing "shift+l" moves map to the right by 100 twice . Also when moving through pins, pressing "n" moves to the next pin, but pressing "shift+n" goes +2 pins and ceneter on it. And it is like that for every key modified by shift. Funny thing is that this behavior can be turned off by pressing "num" key on numeric keyboard (irrelevant if it was on or off when mepo started) and then all "shift+key" work as expected, but then "ctrl+c" can not quit from application. One weird thing is when I press "shift+0" it does two things, moves pin to group 9 and also zooms in (shift+0 is = on HR keyboard), so it looks like it does both keyboard shortcuts "shift+0" from US keyboard and "=" from HR keyboard.

Assigned to
1 year, 3 months ago
1 year, 2 months ago
bug high-priority

~kml 1 year, 3 months ago*

I also have this issue with a German keyboard. The debug output says

Got keybindings table function via textinput with run expression: <move_relative 0 100>
Executing statment: { move_relative, 0, 100 }
Running API function for: move_relative requested by mepolang input statement: { move_relative, 0, 100 }
Processing key in keyup: J

I found the following code in Mepo.zig:

fn event_keyup(mepo: *@This(), e: sdl.SDL_Event) types.Pending {
    if (sdl.SDL_TRUE == sdl.SDL_IsTextInputActive() and
        e.key.keysym.mod == 0) return .None;

My guess is that the e.key.keysym.mod == 0 causes this behaviour. It would also explain your Num key. I do not know what the purpose of the condition was, but removing it seemed to fix the problem for me.

~mil 1 year, 2 months ago

Hmm - thanks for reporting. I think there may be some strangeness based on the SDL TextInput API. Essentially if the TextInput is present, raw text key events are dropped, however this may not be the correct action to take / design. This was done to prevent double event registering.

Thanks ~kml for the investigation work, this will be helpful spot to pick up on when I jump back into this.

Register here or Log in to comment, or comment via email.