-
Notifications
You must be signed in to change notification settings - Fork 64
Wrong keysyms for numpad keys. #94
Comments
Something like this might also work: if (keyEvent->location == DOM_KEY_LOCATION_NUMPAD) {
switch (scancode) {
case SDL_SCANCODE_0:
case SDL_SCANCODE_INSERT:
scancode = SDL_SCANCODE_KP_0;
break;
case SDL_SCANCODE_1:
case SDL_SCANCODE_END:
scancode = SDL_SCANCODE_KP_1;
break;
case SDL_SCANCODE_2:
case SDL_SCANCODE_DOWN:
scancode = SDL_SCANCODE_KP_2;
break;
case SDL_SCANCODE_3:
case SDL_SCANCODE_PAGEDOWN:
scancode = SDL_SCANCODE_KP_3;
break;
case SDL_SCANCODE_4:
case SDL_SCANCODE_LEFT:
scancode = SDL_SCANCODE_KP_4;
break;
case SDL_SCANCODE_5:
scancode = SDL_SCANCODE_KP_5;
break;
case SDL_SCANCODE_6:
case SDL_SCANCODE_RIGHT:
scancode = SDL_SCANCODE_KP_6;
break;
case SDL_SCANCODE_7:
case SDL_SCANCODE_HOME:
scancode = SDL_SCANCODE_KP_7;
break;
case SDL_SCANCODE_8:
case SDL_SCANCODE_UP:
scancode = SDL_SCANCODE_KP_8;
break;
case SDL_SCANCODE_9:
case SDL_SCANCODE_PAGEUP:
scancode = SDL_SCANCODE_KP_9;
break;
case SDL_SCANCODE_RETURN:
scancode = SDL_SCANCODE_KP_ENTER;
break;
case SDL_SCANCODE_DELETE:
scancode = SDL_SCANCODE_KP_PERIOD;
break;
}
} (The main reason this is using |
Note, I only checked the numpad behavior. But potentially there are more differences. Note that your code example changes the scancode, but also the keysym is wrong compared to native SDL. So it would be better to fix the keycode first, and then get the scancode from that as the current code is already doing. It could be that this is a giant can of worms with all the different browsers, that I don't know. |
Yeah, that must be the nature of what I have been experiencing. Numpad is totally fucked. Also of note (and maybe this only affects me for some reason) is that the keyboard is recognized when testing locally in the browser but not hosted on the net and testing with the same browser. As in, no keyboard input at all. Weird. Anyhow, shouldn't the official SDL project be dealing with these issues? I feel sorry for you Emscripten guys having to handle all this browser compatibility bullshit yourselves. |
We only pass the scancode to SDL, we have no control over keysyms. Since the only use of the |
@fluffrabbit I'm the original author for a lot of this backend (including keyboard handling), so pretty much "official SDL" unfortunately (for me). |
@Daft-Freak Whatever that means. Ask Valve to hire some more SDL devs if this is to be a serious backend. I do hope they're paying you. Otherwise, I do not regret the time I have sunk into learning EGL thus far. |
I take it back; web platforms are a waste of time anyways. PC master race. |
Ignoring fluffrabbits rambling. @Daft-Freak the above patch seems to work. Except that KP_5 doesn't work when numlock is off. I do see the javascript event window.onkeydown firing when I press the key, but nothing happens at SDL level. |
Oh, I just noticed, it reports keyCode 12 in javascript, which is mapped to SDL_SCANCODE_UNKNOWN. So mapping that to SDLK_SCANCODE_KP_5 would fix the 5. However, according to https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode Would mapping it to KP_5 be an acceptable solution? As that is the most common key? |
Yeah, that's fine. Just prefix that commit with "emscripten: " and I'll merge it. |
On windows/linux
event.keysym.sym reports SDLK_DOWN for the 4 arrow key down, and SDLK_KP_2 for the down key on the numpad.
On emscripten
event.keysym.sym reports SDLK_DOWN for the 4 arrow key down, and SDLK_DOWN for the down key on the numpad or SDLK_2 depending on the numlock setting.
I think the source of the issue seems to stem from
SDL2/src/video/emscripten/SDL_emscriptenevents.c
Line 503 in 5b79532
Which uses "keyEvent->keyCode" which comes from:
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
But a better option to get a scancode would be to use the keyEvent->code, which contains a string representation of the scancode.
The text was updated successfully, but these errors were encountered: