> If you are so keen on the symbolic mapping, could you please explain why the "scancode" mapping is not working for you?
Okay, I will try to explain why Symbolic and Scancode are not equivalent, but can I ask that you stop addressing me personally like this? Both here and in the github replies. This is not about what "works for me". I am not trying to figure out how to configure Hatari for myself. I do not need to be told 6 times that scancode mapping exists. I know about it. I've used it. It's good for it's purpose. However, different users have different purposes. Even the same users has different purposes at different times. Please don't make this about ME. I'm trying to address the utility of Hatari for everybody.
What I want is for it to be easier for users to make good productive use of Hatari, without having to go through additional steps to custom-configure their keyboard mapping. The custom options should remain, they are great to have, but it would be nice if the default user didn't have to go to this extent to make the keyboard usable.
We have two mapping paradigms:
- Scancode mapping approximately maps a physical location on the host keyboard (SDL scancode) to a physical location on the emulator keyboard (ST scancode).
- Symbolic mapping is a key semantic on the host keyboard (e.g. "Q key") to a physical location on the emulator keyboard (ST scancode). This virtualizes the host keyboard, but with the tradeoff that the physical locations can be different.
The scancode mapping works pretty well if your host keyboard layout is similar to the ST keyboard layout for the version of TOS you are using. However, when they do not match, it requires the user to memorize a different layout foreign to them. If we run a French program with a US host keyboard, we can't look down at the keyboard to find Q or W, we have to memorize the differences. This is a mental burden for the user, or if they choose to customize the mapping to address this, it's a burden of effort. It's sensible for Hatari to supply common mappings where host matches TOS, but a few hundred permutations of host vs. TOS are out of the question.
The symbolic mapping addresses these mismatches very well. SDL provides this feature because it's useful for exactly this kind of things. We can take any host keyboard, and forget about what its layout was. Q comes out Q no matter where it was typed on the keyboard. The letter you see on your keyboard will match the output we're getting.
The problem with the current symbolic mapping is that its ST scancodes are specific to the US TOS keyboard layout (with the noted exception of SDLK_MINUS for which the fix was resisted). With the symbolic mapping you can take most keyboard layouts + US TOS and what you see on the keyboard matches what you get on the screen very well. There are always exceptions, especially when it comes to shift/alternate forms, but the majority of stuff works great this way.
What I've been working on, is providing a set of 16 symbolic maps for the keyboards known to me (
https://tho-otto.de/keyboards/ ) and allowing Hatari to automatically select the chosen one based on the loaded TOS, or override if the user chooses. Because the number of TOS languages is finite and small, it's a reasonable amount of code to provide this. With SDL providing the semantic mapping, we eliminate one side of the host vs. TOS permutations and it's reduced to a solvable problem.
I was thinking about this because I had to work through all 16 layouts to provide them as on-screen keyboards in my Libretro adaptation of Hatari (
). It gave me an idea of the scope of the work, and where all the exceptions lie. I think it's feasible. I've already done a couple of layouts and they seem to be working very well. I just need some time to finish going over all of them. It's not complicated work, just takes time to get through all the data entry and testing.