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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi Brad,

On 15.2.2024 2.23, Brad Smith 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.

Please post whatever you have (either as draft/WIP patch set here, or PR on GitHub).

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": https://askubuntu.com/questions/56560/what-exactly-is-meant-by-eliminate-dead-keys


	- Eero

PS. Attached is helper to get TOS keyboard language either from NVRAM or ROM.

KBD selection is then something like:
+       const name2key_t *map;
+       const int layout = TOS_GetKbdLayout();
+
+       switch (layout)
+       {
+       case TOS_LANG_DE: // 1
+               map = (const name2key_t *)map_de;
+               break;
+       case TOS_LANG_FR: // 2
+               map = (const name2key_t *)map_fr;
+               break;
+       case TOS_LANG_UK: // 3
+               map = (const name2key_t *)map_uk;
+               break;
....
+       LOG_TRACE(TRACE_KEYMAP, "TOS %d (%s) keyboard layout mapping %s\n",
+                 layout, TOS_LanguageName(layout),
+                 map ? "initialized" : "not initialized");


-- 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



From eb36c839ce1c1bc1cbac35599eb04ae26251d8b9 Mon Sep 17 00:00:00 2001
From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
Date: Sat, 20 Nov 2021 02:07:31 +0200
Subject: [PATCH] Add TOS_GetKbdLayout() -> NvRam_GetKbdLayout()

Used by keymap code later.
---
 src/falcon/nvram.c |  5 +++++
 src/falcon/nvram.h |  2 ++
 src/includes/tos.h |  1 +
 src/tos.c          | 13 +++++++++++++
 4 files changed, 21 insertions(+)

diff --git a/src/falcon/nvram.c b/src/falcon/nvram.c
index a639cdd2..be863796 100644
--- a/src/falcon/nvram.c
+++ b/src/falcon/nvram.c
@@ -565,3 +565,8 @@ void NvRam_Info(FILE *fp, uint32_t dummy)
 	fprintf(fp, "- SCSI ID: %d, bus arbitration: %s (30)\n",
 		nvram[30] & 0x7, nvram[30] & 128 ? "off" : "on");
 }
+
+int NvRam_GetKbdLayout(void)
+{
+	return nvram[NVRAM_KEYBOARDLAYOUT];
+}
diff --git a/src/falcon/nvram.h b/src/falcon/nvram.h
index 23645407..583b304f 100644
--- a/src/falcon/nvram.h
+++ b/src/falcon/nvram.h
@@ -56,4 +56,6 @@ static inline bool NvRam_Present(void)
 	       ConfigureParams.System.nMachineType == MACHINE_FALCON;
 }
 
+extern int NvRam_GetKbdLayout(void);
+
 #endif /* HATARI_NVRAM_H */
diff --git a/src/includes/tos.h b/src/includes/tos.h
index a14525ec..3a67d5bc 100644
--- a/src/includes/tos.h
+++ b/src/includes/tos.h
@@ -57,5 +57,6 @@ extern int TOS_DefaultLanguage(void);
 extern int TOS_ParseCountryCode(const char *code);
 extern void TOS_ShowCountryCodes(void);
 extern const char *TOS_LanguageName(int code);
+extern int TOS_GetKbdLayout(void);
 
 #endif
diff --git a/src/tos.c b/src/tos.c
index f8f9903c..df86326a 100644
--- a/src/tos.c
+++ b/src/tos.c
@@ -1332,3 +1332,16 @@ const char *TOS_LanguageName(int code)
 	}
 	return "Unknown";
 }
+
+/**
+ * TT & Falcon TOS versions take kbd layout from NVRAM,
+ * other TOS versions base it to ROM country code
+ */
+int TOS_GetKbdLayout(void)
+{
+	const int machine = ConfigureParams.System.nMachineType;
+	if (machine == MACHINE_TT || machine == MACHINE_FALCON)
+		return NvRam_GetKbdLayout();
+	else
+		return STMemory_ReadWord(TosAddress+0x1C) >> 1;
+}
-- 
2.39.2



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/