Linux keyboard layout

[kalenk]

On Linux, if you choose control in the English layout, you can write in chat only in the English keyboard layout. And to make management in another language, then in chat you can write in the language in which it is selected in management.

And you can’t change the keyboard layout for character control back.

[efroemling]

And you can’t change the keyboard layout for character control back.

I'm not sure I'm understanding; can you clarify? So if you switch your system keyboard settings you are able to type in different languages, but that messes up character control somehow?

[Dliwk]

Hmm, I think he says following (rarely did I get something like this): he can't control his character (any movement) but can use chat and other like manual camera, etc. and setting keyboard layout back doesn't help.

[kalenk]

Hmm, I think he says following (rarely did I get something like this): he can't control his character (any movement) but can use chat and other like manual camera, etc. and setting keyboard layout back doesn't help.

everything is correct

[Dliwk]

I remembered another issue like this: I can use my keyboard like gamepad (control character, use UI) only if game started with English keyboard layout (setting it after game start doesn't help).

[Dliwk]

I can't say for sure, but maybe something is wrong with setting up key callbacks, e.g. binding only English WASD key (or another from settings), but while game starts it can't detect these keys correctly?

[efroemling]

Oh; interesting. I wonder if switching the keyboard causes the game to receive different key values for its presses. Could somebody try switching the keyboard layout and then configuring the keyboard while in that language and see if it works? I wonder if we'll need to allow binding multiple keys per action or something to support switching keyboards in this way...

[efroemling]

Also, perhaps a better way to dig into this would be experimenting with the _ba.capture_keyboard_input() and _ba.release_keyboard_input() calls; one could wire those up and see what values the game is delivering; I would be curious if those will change when the keyboard layout changes. To see an example of their use, look at ba_data/python/bastd/ui/settings/keyboard.py in AwaitKeyboardInputWindow (used by the keyboard config ui)

[Dliwk]

Ok, here's what I got: the game uses keys all time from keyboard layout that was when the game started; switching the layout after that has no effect.

And 'button' field of event from _ba.capture_keyboard_input() is just utf8 number of button name (and switching the keyboard layout after starting the game doesn't have any effect too).

[efroemling]

Hmm; this may be an issue with the SDL library which Ballistica uses for input. The values that show up in the capture_keyboard_input() callback come pretty much straight from SDL's SDL_KEYDOWN messages. My guess is that building one of SDL's simple example apps would exhibit the same issue with values not changing on keyboard layout changes.

If anyone wants to mess around with a test app and see if there's a way to get SDL to do the right thing in this case I'd be happy to translate any solution to the game. Or perhaps a fix could be submitted to SDL. I also plan to get much of the C++ layer into the Ballistica repo so folks can poke around directly themselves, but I haven't gotten that done yet.

[efroemling]

I poked around a bit, and it does appear that SDL is supposed to respond to keyboard layout changes: http://lists.libsdl.org/pipermail/commits-libsdl.org/2015-October/000493.html

Perhaps that is somehow not working in this case? Or do you have a very old SDL library perhaps? (that change is from 4-5 years ago). Again, I think a simple example app that just runs the SDL event loop and prints key-press values might help diagnose/pinpoint the problem if anyone wants to give that a try.

[Dliwk]

Simple example behaves the same way (event.key.keysym.sym) but event.button.button takes the same values for different layouts :thinking:

And I have latest stable SDL installed (2.0.12)

[efroemling]

event.button is mouse button events I believe, SDL_Event docs so that wouldn't change based on keyboard layout.

However if a simple SDL example is suffering from the same problem as the game then we may just have to live with the problem for now, unless someone wants to try to fix it or find a workaround on the SDL end... 😕

[Dliwk]

Just heads-up, thing are definitely different now: I can play using my keyboard if and only if current layout is English (corresponds to keybinds) unlike the behavior a year ago.

[efroemling]

I don't think any of the engine keyboard handling has changed in the last year or two, so perhaps this reflects something changed in SDL. All of the keyboard handling code is open source so it should be possible to see what's going on by scattering some printf() or Log() calls around src/ballistica/input/device/keyboard_input.cc and src/ballistica/input/input.cc

[Dliwk]

We-e-ell ok, I've just tested this with SDL2 hello world and it behaves the same way, and as I can remember.. it seems.. a year ago it worked the old way.

[Dliwk]

Oh this is totally crazy issue :rofl:

Now game (and SDL itself) behave for me the way they used to behave 2 years ago.. does that thing change every year?.. I can't get it.

(Note for myself when I'll check this a year later: right now I'm using Fedora 36 on my laptop with SDL2-2.0.22-2.fc36).