Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect existing keymap #281

Open
zzaba opened this issue Mar 10, 2021 · 4 comments
Open

Respect existing keymap #281

zzaba opened this issue Mar 10, 2021 · 4 comments
Labels
Milestone

Comments

@zzaba
Copy link

zzaba commented Mar 10, 2021

It would be nice if game respected existing keyboard mappings.
I have caps lock and escape keys switched with setxkbmap , so every time I press escape in game caps lock is toggled, which is very annoying. Also in order to change player name I have to use qwerty, which is not my preferred (and system-wide) layout.

@laochailan
Copy link
Collaborator

Hi,

in general, we use scan codes for in-game inputs to allow people with nonstandard layouts to play the game without having to remap their buttons. For games this is often preferred behavior because the position of the keys matters more than what is on the keys. If people don’t like this, in most cases they can still remap their controls. Escape is of course a problem, because it cannot be remapped. Maybe we should introduce an explicit mapping for the ingame menu key, too? and make mappings to the escape key possible?

I cannot reproduce the player input issue. For me the name input is in my system-wide nonquerty keyboard layout set via setxkbmap. Are you perhaps using something more complicated like ibus?

@Akaricchi
Copy link
Member

I have caps lock and escape keys switched with setxkbmap , so every time I press escape in game caps lock is toggled, which is very annoying.

I don't understand the issue here... if you've swapped escape with capslock, and you expect the game to respect the keyboard layout, then wouldn't you also expect it to interpret escape as capslock and vice versa? Please elaborate.

Also in order to change player name I have to use qwerty, which is not my preferred (and system-wide) layout.

We use SDL's text input API for that (SDL_StartTextInput and SDL_TEXTINPUT), which is expected to respect the system keymap, and even handle stuff like IME input. If that doesn't work, then it's probably an SDL bug. Taisei doesn't interpret individual keypresses there, it simply receives a buffer of UTF-8 text input from SDL.

@zzaba
Copy link
Author

zzaba commented Mar 10, 2021

Indeed, reinstalling SDL fixed issue with the layout.

I have setxkbmap -option caps:swapescape in my .xinitrc.
Normal behavior (outside taisei):

  • Press escape key - toggle caps lock.
  • Press caps lock key - escape.

Current taisei behavior:

  • Press escape key - navigate the menu and toggle caps lock.
  • Press caps lock - nothing.

Desired taisei behavior:

  • Press escape key - toggle caps lock.
  • Press caps lock - navigate the menu.

Introduction of an explicit mapping for the in-game menu key is nice idea. As well as being able to remap it in controller settings.

@Akaricchi
Copy link
Member

Ah I see now, that makes sense. We discussed this on discord a bit. Probably the cleanest way to fix it is to check for Escape and Return by keysym - these keys are "special" in that you want to press them by meaning and not by position. This approach might cause minor problems in some very contrived cases; e.g. if you've mapped escape to left shift or something, you'll have to change the default controls in order to play. I don't think we can account for every silly edge case like this though. Overall it seems like the right thing to do.

@StarWitch StarWitch added this to the v1.4 milestone May 8, 2021
@StarWitch StarWitch added this to To do in Accessibility via automation May 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Accessibility
  
To do
Development

No branches or pull requests

4 participants