Re: [hatari-devel] Recent symbolic keyboard mapping change

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 4.10.2024 20.56, Brad Smith wrote:
> If you would like it split up, I would need some guidance about what you
> feel should be an individual coherent step here.
>> If you look at the PR, you should see that there are zero logical code
> changes. All of this is changes to individual switch statements.

You PR has detailed description of the changes, but the commits do not.

Maybe you could split the description to several parts, and include each 
part to a commit doing that change?


> Aside from key case changes, in my version I had written it so that NVRAM
> is not allowed to affect the keyboard mapping unless the TOS was identified
> as a multi-language TOS. In your version, you did not include this in your
> revision. I did not attempt to restore this in my PR, but I do not know why
> you chose to discard it, perhaps you could comment? The reason I had done
> this was that I didn't think it made sense to allow NVRAM settings to
> change the symbolic mapping in conflict with the one the TOS can actually
> support. To me the case where this would happen would be the Falcon user
> switching from emuTOS to an original TOS that was not the same language as
> their NVRAM setting, and I felt that in this case the user would want
> mappings that work with the TOS in this case.

Good point.  While only TT and Falcon include NVRAM, and both of those 
(can) have TOS version supporting multiple keyboard layouts, all TOS 
versions do not support the same set.

E.g. older EmuTOS versions support fewer ones than latest release, but 
for that case I think we can just document that keyboard selection 
assumes specific EmuTOS version, or newer.

As to original TT/Falcon TOS versions, I'm not sure to what keymap they 
default to, if NVRAM has country code value it does not recognize.  US 
maybe?

Symbolic keymapping should match the keymap used by TOS, otherwise it 
won't work properly.


	- Eero