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

[Input] Fix keyboard layout issues on Windows #269

Closed
wants to merge 1 commit into
base: develop
from

Conversation

Projects
None yet
7 participants
@Frassle
Contributor

Frassle commented Jun 2, 2015

Changes the Windows keyboard handling code to return keycodes based on keyboard layout. So Key.A is triggered when the A key is pressed, not when the first key on the home row is pressed (old behaviour that only looked at scancodes).

Fixes #260

ilexp referenced this pull request Jan 24, 2016

@ilexp

This comment has been minimized.

Contributor

ilexp commented Jan 24, 2016

Considering merging this into my own fork of opentk, but I can't afford to break things in the process, so I'll ask just to be sure: Is there a specific reason why this hasn't been merged into develop yet?

@Frassle

This comment has been minimized.

Contributor

Frassle commented Jan 25, 2016

Testing I did suggests its ok, but it is quite a big change in behaviour so hacks people had to work around keyboard issues before will need to be changed/removed.

@ilexp

This comment has been minimized.

Contributor

ilexp commented Jan 25, 2016

Ah, I see :) Thanks!

Edit: Mirrored here.

@ilexp

This comment has been minimized.

Contributor

ilexp commented Feb 15, 2016

I've been thinking about this issue a bit and am skeptical as to whether this should be merged. Quoting from the above referenced issue:

The current situation is, OpenTK (and Duality) assumes an american QWERTY keyboard layout and will report key events regardless of whether or not the user actually has a different layout. This means, the key that is at the position where, on the american keyboard, Q is, will always be reported as the Q key, regardless of the character output it produces or the letter that is printed onto the physical key.

Contrarily, using virtual keys will make sure Q will always be where the physical key with the Q letter is. A Q will always be a Q, but the position changes.

Now imagine you develop a game with WASD movement and deploy it. What would you expect: That the default control settings always map to the actual W, A S and D keys, or that the control settings still map to the keys in the same physical location - even though the letter on them may be different?

Putting it in other words: Right now, the default key input will result in us all having the familiar "WASD" controls (WASD for QWERTY keyboards and ZQSD for AZERTY keyboards) - whereas switching to a layouted virtual key model will result in everyone with a different keyboard layout having to remap their keys so they are in the proper physical location.

Games are different to text processing software in that the physical location of the key matters more than the meaning of the key. (And if you really need to know the character input you received, there are existing and better ways to receive it.) Therefore, I'm currently in favor of keeping things the way they are.

Please correct me if I'm wrong.

@cra0zy

This comment has been minimized.

Contributor

cra0zy commented Feb 26, 2016

@amulware Let's put or priority on going over this PR :) I'll try going over it after I am done with my system reinstallation.

@amulware

This comment has been minimized.

Member

amulware commented Feb 26, 2016

@cra0zy Sounds good. I don't understand all the changes to the code from quickly looking at it (so I cannot confirm if everything makes sense), but I get the general point.

I also see @ilexp's argument above however. Not sure where I stand on that at the moment.

@tyronx

This comment has been minimized.

Contributor

tyronx commented Jun 29, 2016

@ilexp, dude that argumentation fails to address one important point: a game can always support custom key mappings, but it can't fix broken key events by a third party library! I want OpenTK to report the correct key, not the correct key location. What do I care for a correct key location when the reported key is wrong? Plus, it obviously doesn't even report the correct key location in certain instances.

@tzachshabtay

This comment has been minimized.

Contributor

tzachshabtay commented Jun 29, 2016

I'm 95% agreeing with @tyronx.
I think, ideally, the library can support both (i.e have 2 sets of events: KeyDown + KeyDownOnLocation for lack of a better name).
But if there can be only one, then no doubt about it, the current implementation is the wrong one (as the WASD scenario can easily be worked around with custom mapping, but you can't expect the user to map all the keys on his keyboard if the game involves typing...)

@ilexp

This comment has been minimized.

Contributor

ilexp commented Jun 29, 2016

WASD scenario can easily be worked around with custom mapping, but you can't expect the user to map all the keys on his keyboard if the game involves typing...)

Typing is not a useful scenario for key events. There are already window events where you can get pre-parsed char values from the OS, including special rules like typing while the shift or alt key is pressed, special characters, and so on. If you were to actually implement text input based on key events, you'd be up for way too much work.

I think, ideally, the library can support both (i.e have 2 sets of events: KeyDown + KeyDownOnLocation for lack of a better name).

I agree completely and as far as I know, SDL2 (I think? Don't recall which library it was) went down a similar road by separating KeyCode (mapped) and ScanCode (physical location) and providing both. This could be a great solution for OpenTK as well.

Plus, it obviously doesn't even report the correct key location in certain instances.

Starting with USB, it seems like a lot of those keys are standardized: Wikipedia: Scancode#USB. Apparently, it's not all of the keys, but a reasonable subset of them. Please do correct me if I'm wrong, I merely just googled this.

But if there can be only one, then no doubt about it, the current implementation is the wrong one

I disagree for the reasons already stated. Since typing and character input is already covered, what remains is key input for non-text purposes. In this context, the keyboard is nothing more than a somewhat standardized, fancy joystick or gamepad with only buttons and no axes. What do you care more about: Where each of those buttons are or what the manufacturer has decided to write on them, depending on where that device was bought?

Illustrating it differently: Think of a gamepad where you can only query the buttons by the symbol that is printed on them, but there is no straightforward way to ask the gamepad which layout it uses, and users can even reconfigure that on an OS level. Do you really want to send so many players into the options menu right away?

tl;dr: Either do both (which would be really neat!), or keep it location-based only. We already have a different API for text input.

@tzachshabtay

This comment has been minimized.

Contributor

tzachshabtay commented Jun 29, 2016

Typing is not a useful scenario for key events. There are already window events where you can get pre-parsed char values from the OS, including special rules like typing while the shift key is pressed.

Wait, really? Where are those events located? Can you give an example?

Anyway, even if this is true, there's still a case to be made for this fix: any serious game will have configurable keys anyway, and you can't create an accurate key mapping UI since you don't know the key name (i.e the user will press "P" and the UI will show "W" -> very confusing for the user).

@tyronx

This comment has been minimized.

Contributor

tyronx commented Jun 29, 2016

@ilexp With the current key translation some keys are wrongly translated. When I press Fn+F12 on my Inspiron 15z laptop - which is Volume Up - opentk fires a keydown event for the key "B" see also #396 (comment)

@ilexp

This comment has been minimized.

Contributor

ilexp commented Jun 29, 2016

@ilexp With the current key translation some keys are wrongly translated. When I press Fn+F12 on my Inspiron 15z laptop - which is Volume Up - opentk fires a keydown event for the key "B" see also #396 (comment)

This does need to be fixed, but I don't think abandoning scancodes altogether would be a great fix for this.

Something better (for now) might involve checking that it's an extended key and providing some generic scancode (ExtendedKey1234) instead - which I would consider a quick fix for falsely reporting B, with the overall (long-term) solution of separate KeyCodes and ScanCodes in mind.

Let's not discuss this specific issue here though.

Typing is not a useful scenario for key events. There are already window events where you can get pre-parsed char values from the OS, including special rules like typing while the shift key is pressed.
Wait, really? Where are those events located? Can you give an example?

GameWindow.KeyPress, as inherited publicly from NativeWindow.

Anyway, even if this is true, there's still a case to be made for this fix: any serious game will have configurable keys anyway, and you can't create an accurate key mapping UI since you don't know the key name (i.e the user will press "P" and the UI will show "W" -> very confusing for the user).

I agree that this is not ideal, but the proper solution would be to have both, not to replace the existing scancode-based code with something that serves their main purpose badly. Until then, you probably can use the text and key input simultaneously to provide a named feedback.

@varon

This comment has been minimized.

Member

varon commented Dec 12, 2016

Closing, as this is both ancient and would need to be re-made against the updated project structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment