> I noticed that you merged some symbolic key mapping changes. Did you check the changes against *all* (EmuTOS/MiNT) supported keyboard layouts:
I did review these. This has been my main point of reference in reviewing keyboard mappings.
The accepted changes:
$1A [ was mapped only to an anonymous code 252, and $1B ] had no mapping at all. These should have been SDLK_LEFTBRACKET and SDLK_RIGHTBRACKET, which had been redundantly assigned to parentheses scancodes ( ) instead.
$29 was mapped only to SDLK_HASH, which is not present on US keyboard layout. SDLK_BACKQUOTE is the correct US layout key for $29, but it was assigned to $52 instead. $52 was already mapped to SDLK_INSERT, which I believe is present on all keyboard layouts. Since $52 is universally accessible, SDLK_BACKQUOTE should be allowed its US mapping so that it is not an unpressable key there.
The rejected but resubmitted change I'll explain my rationale here:
SDLK_MINUS should be $0C, rather than its current $35.
The symbolic mapping is the default configuration of Hatari, which users will receive without any further configuration. This comment in the mapping states that it assumes a "QWERTY ST keyboard", and with the recent changes plus this proposed change the default setup gives a 100% complete US layout + US TOS key coverage. There are also many non-US-layout symbolic mappings which are included, but these are good for convenience and are not a problem.
$0C is the correct mapping for US, UK, Spanish, Dutch and Polish layouts.
$35 is the correct mapping for German, Italian, Swedish, Swiss, Finnish, Norwegian, Czech, and Hungarian layouts.
$0D is the correct mapping for French.
My rationale for $0C is that using $35 may accommodate pressing MINUS for the listed layouts, but for all of those cases the symbolic mapping has many, many other mappings besides this one key. The US layout, on the other hand, would be 100% correct if it used $0C.
So, I think it is best to use $0C so that the default keyboard setup works 100% for its main target, and not to make an exception for only the MINUS key on targets for which the rest of the symbolic mapping is already unacceptable.
> IMHO before we go with any bigger extension of the keyboard mapping code, we should mostly get rid of the symbolic mapping code in that file. It's mostly a leftover from the SDL 1.2 era where the scancode mapping was not working reliably on all host OSes.
I think the symbolic mapping is worth keeping, at least for now.
It's clear that the its mappings are not adequate for many language layouts, but the fact that it does work perfectly for US layout (with the 1 proposed change) does make it useful for many users.
So... for some users Hatari's keyboard can just work out of the box. For many other users, they need to do some setting changes. I think this is at least a better situation than having all users needing to figure out their keyboard settings. At least some can be accommodated easily this way.
I'm not trying to assert that US layout is the best default, but between the existing comments and scancodes, it's the one the symbolic mapping we have in the code actually matches, and I think we should make it do that much properly, and the proposed change to provide it is very small.
In the longer term, maybe we can do something to make it easier for everybody. I know it's a hard problem. You could query the OS keyboard layout, or check their TOS language, but the combination unfortunately becomes ambiguous. Maybe we could provide a built-in collection of common layouts in the keyboard settings? I'm sure we have many ideas.
-- Brad Smith