Re: [hatari-devel] Minus key is mapped to / in Hatari when using KEYMAP_SYMBOL

[Chris Jenkins <cdpjenkins@xxxxxxxxx>]

It turns out that the thread that I couldn't find is "Recent symbolic keyboard mapping change" from August/September 2023.

In that thread, Thomas describes the symbolic mapping as an ugly hack left over from the era of SDL 1.2 and recommends using the scancode mapping, so that's what I'll do. Scancode mapping works ok for me.

Would it be worth deprecating the symbolic mapping and having Hatari default to the scancode mapping?

Cheers,

Chris

On Thu, 15 Feb 2024 at 07:35, Chris Jenkins <cdpjenkins@xxxxxxxxx> wrote:

Many thanks Brad. Where can I find previous discussion of this issue? I didn't find it when I searched last night, and still can't find it now :-(. Is there a thread on this list that I missed, for example? If I can find it then there's no need for this thread.

Cheers,

Chris

On Thu, 15 Feb 2024, 00:24 Brad Smith, <rainwarrior@xxxxxxxxx> wrote:

The real problem is that we need a different symbolic mapping for each locale of TOS.

Last September I proposed that SDLK_MINUS should be mapped to 0x0C, and then the symbolic mapping would be complete and correct for US TOS at least, which is the one layout it is closest to being a perfect match for. Otherwise the symbolic mapping has many poor mappings for every other possible TOS locale.

 However, this change was resisted, with others stating that SLDK_MINUS had to remain 0x35.

I gave an alternative proposition, which I haven't finished implementing, which is to create a set of symbolic mappings, one for each TOS locale, which are selected by the normal TOS locale detection. This way, the host's keys map to SDL symbols, and then the SDL symbols map correctly to the TOS being used.

I have implemented a few languages already, but I haven't finished completing the set yet.

-- Brad Smith

On Wed, Feb 14, 2024 at 4:08 PM Chris Jenkins <cdpjenkins@xxxxxxxxx> wrote:

Hi,

I noticed that, when using Hatari on my UK Mac with the symbolic keymap, the - (minus) key is mapped to the / (forward slash) character in UK TOS or emutos. This doesn't happen when using the scancode keymap or if I define a keyboard mapping file that explicitly maps the minus key to the standard VDI scancode for minus. It also doesn't happen if I use a German keyboard layout on my Mac.

Looking at the function Keymap_SymbolicToStScanCode in keymap.c, I can see the following:

case SDLK_MINUS: code = 0x35; break;

Looking at at  https://freemint.github.io/tos.hyp/en/scancode.html, 0x35 (decimal 53) is the scancode for the minus key in the German keyboard layout (as well as several other national keyboard layouts) but in the USA layout (and he UK layout, and in the standard VDI scancodes) it is the scancode for the / (forward slash) character.

Given that the comment for Keymap_SymbolicToStScanCode says "This assumes a QWERTY ST keyboard", would it make sense to map SDLK_MINUS to 0x0C (the minus key in UK/USA/standard VDI scancodes)?

The attached patch does this, and fixes the problem for me and my UK Mac keyboard layout. I confess I'm not quite sure what the full implications are, though. Will this break something for users of German (and other) keyboard layouts?

Cheers,

Chris