On Fri, Feb 16, 2024 at 7:01 PM Eero Tamminen <
oak@xxxxxxxxxxxxxx> wrote:
>
> I'd like to take a look at how you're solved keyboard selection, and
> especially the modifier issue.
>
> I.e. that generating certain symbolic keys on PC requires using modifier
> keys (shift, altGr etc), which should not be sent to emulation.
>
> Then there are also "dead keys"
I don't think this is the problem we should be solving with this mechanism.
My goal is not to re-implement the modern OS input method. It is more simply to provide a sensible mapping of SDL's symbolic set to the emulated Atari ST scancodes. It is essentially the same as what is already there, but resolving the issue that SDLK_MINUS represents: the only sensible mapping for this key in US TOS is $0C, and the only sensible mapping for German TOS is $35. We can't have both at once, but if we know which TOS is being used, we can disambiguate it. With a set for each TOS, I feel that Hatari's symbolic input as a default will work "pretty good" out of the box for most users, and we can do away with having to require so many people to manually configure their mappings.
So, dead key functionality would be the duty of the emulated operating system, not of Hatari.. Hatari is just relaying SDL keypresses to a sensible emulated scancode. (TOS does not have dead key input, does it? I could imagine MiNT or some alternative emulated OS providing it, but I don't have experience with it.)
Modifier keys in the same way are not manipulated, just passed along. The point is that typing characters should work and feel more or less like input on the original keyboard. AltGr is not an ST key, so it's not how we activate a modifier here.
Please clarify if I misunderstood, but it seems like you are suggesting that this should remap semantically every possible modified key, and I feel this would be tremendously complicated and unproductive. For example, in theory we could detect "shift + 6" and then check the host OS to decide whether the user meant '^' (US) or '&' (German) and then check the target TOS locale and resolve that combinatorial problem of US to US (2A+09), US to German (2A+29), German to German(2A+09), or German to US (2A+08). This example already feels untenable at just 2 languages, and I don't think anyone really needs this as a feature.
The most important case is where the host language matches the TOS locale. Mapping one host language to a different TOS locale also mostly works, though yes of course many modified keys will be unintuitive in such a combination, but I don't feel that's an important problem to resolve. It's enough of a benefit to have the matching host vs TOS work nicely, without trying to solve the combinatorial edge case of mismatched modified keys.
If we did want such a thing, I would suggest instead using SDL_TEXTINPUT events to obtain UTF-8 characters from the OS and then map those to the TOS locale. SDL_TEXTINPUT would use the host's input method with its own modifiers/deadkeys/etc. rather than trying to re-implement it from scratch based on SDL_KEYDOWN events. However, I don't feel this is a feature worth pursuing.
There is a potential dead key issue that I might ask about, whether SDL would hide a keypress if it was a dead keystroke on the OS. I find that on Windows, this is not the case. The dead keystroke will still generate the SDL key event we want to pass along, so there is no problem. However, you mentioned Ubuntu and Norwegian allowing the user to select two different input methods. Does SDL behave differently for this case in Linux, or does it simply pass the dead keystroke as an event like on the Windows version? I would expect it to pass it along, since that seems to be inherent in the definition of SDL's interface, but I don't have a Linux environment set up to test that easily at this moment.
>
Please post whatever you have (either as draft/WIP patch set here, or PR
> on GitHub).
> PS. Attached is helper to get TOS keyboard language either from NVRAM or
> ROM.
I found that in tos.c we are already deducing a "countrycode" variable at boot, so I just passed that value to the keymap system to select a map.
-- Brad Smith