Fix keymappings for -_ [{ ]} and ~

[bbbradsmith]

There are 3 keys that are un-typable with the current keymap:

• -/_ scancode 0x0C - SDLK_MINUS
• [/{ scancode 0x1A - SDLK_LEFTBRACKET
• ]/} scancode 0x1B - SDLK_RIGHTBRACKET

SDLK_MINUS was mapped to redundantly //? and the two brackets were mistakenly mapped as parentheses ( and ) instead. I couldn't find any way to type these 3 keys before this change.

Edit: Found one more:

• back quote / ~ scancode 0x29 - SDLK_BACKQUOTE

BACKQUOTE had been mapped to the Insert key instead.

[huth]

For the records: Which keyboard layout are you using on your computer? English from the US?

And what TOS language version are you using in the emulator?

[huth]

I've now read through the changes, and I agree with all modifcations but the SDLK_MINUS one: That breaks the corresponding key on my German keyboard. I think that key is different on various languages, so there is no good solution for this. Anyway, I'd recommend to use the scancode based mapping instead of the symbolic mapping to avoid these problems. I've merged the other changes now, so I'm closing this PR.

[bbbradsmith]

Yes, I'm using Windows 10 with the US keyboard layout. The TOS setting is sort of a misdirection, because the real problem is that there is no mapping from any available key to Atari ST scancode 0x0C.

SDLK_MINUS is the code given by that key for this keyboard. SDLK_UNDERSCORE does not exist. 223 does not exist. I can use a German TOS, but scancode 0x0C can't be generated through this mapping, regardless of TOS.

So, that's the problem I was addressing. On a US layout keyboard there exists no way in Hatari to press this key with the default setup, regardless of TOS setting.

If I set my Windows keyboard mapping to German. The key in the top right, two to the left of backspace which is - on US layout becomes instead ß. Instead of SDLK_MINUS (45), it now reports 223. Additionally the key in the bottom right /? SDLK_SLASH (47) in the German setting becomes SDLK_MINUS (45).

So, I see why this is a problem for the German keyboard in the default mapping. Its SDLK_MINUS (45) wants to go to ST scancode 0x35 on German TOS, and already has access to ST scancode 0x0C via 223 ß.

Unfortunately SDLK_MINUS cannot have both meanings at once, so either US keyboard or German keyboard users cannot type - and underscore in the default settings, assuming their TOS matches their system keyboard layout anyway...

I will say that In the default as-is (with the merged changes), every key except -/_ works with the default setting in US layout + US TOS, which I think is good. Does this hold true for German layout? What about others? I guess that key in particular is all over the place...

I guess the main problem is that the mapping is only one or the other. Possibly it could select 0x35 vs. 0x0C etc. based on the detected TOS since at least SDL finds our system's - key for us, though this kind of solution should apply to more than just that key.

[bbbradsmith]

Okay looking at this some more, I think I would recommend the change to SDLK_MINUS still.

The reason for this is that the default mappings in Keymap_SymbolicToStScanCode are entirely US layout otherwise, and not German layout, so making this one key favour the German output contradicts it for only one key.

Please tell me if I am wrong about this, but tell me about the following setup:

• Hatari default settings (symbolic keymap)
• German TOS
• German host keyboard

Type a Y or a Z, and which does TOS display?

I don't have a physical German keyboard to test, but if I set my Windows 10 keyboard layout to German, it will report SDLK_z for my physical Y key (i.e. QWERTY reports as QWERTZ), which is what I'd expect. However, SDLK_z is mapped to 0x2C, which is the US mapping.

So, what I am led to believe is that the entire mapping is consistent on US host + US TOS (except the SDLK_MINUS in question), but the German host + German TOS mapping has every key that's different from the US wrong, except the SDLK_MINUS which has been made an exception.

Is this a correct assessment? Does it behave that way on your system? I am only simulating what I can with the hardware I have here in Canada.

If I am correct, would it not make more sense for all the keys to be consistent, and have SDLK_MINUS use the US mapping in this default setting?

[huth]

Hi Brad! Looking at the various language keymaps, there are some languages like Danish or Hungarian that have Y and Z in the same location as the US keyboards, but the "-" key is in the same location as on the German keyboard. I'm sorry, but there is no perfect solution to keep everybody happy here.

[bbbradsmith]

there are some languages like Danish or Hungarian that have Y and Z in the same location as the US keyboards, but the "-" key is in the same location as on the German keyboard.

Both of those keyboard layouts have several keys wrong by this mapping. The US keyboard has only this one single key out of place. I still think it's better to have 1 keyboard layout actually work, than insist every layout needs to have a few keys broken.

[huth]

Could you please try the "scancode" mapping? That should really be the best option.

[bbbradsmith]

I'm sorry I feel like there is a strange misunderstanding here. I'm not asking for help setting up my Hatari keyboard settings. I'm very much aware of the scancode option. They're good for their purpose. I'm not proposing to make any changes to those.

This was a proposal for a small and very easy change which should improve the symbolic mapping, which has a different function than the scancode mapping. That difference gives it a very valid use, in my opinion. It's worth keeping, and worth improving for the benefit of some users.