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

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


So, the symbolic mapping system is not really capable of addressing this problem. The symbolic SDL interface abstracts away what the host keyboard is, that's kind of its purpose. There is no way to query "is this a JIS keyboard" or "does this keyboard have an = key", stuff like that is out of scope.

What this effort is trying to do is primarily cover the case of the host keyboard being the same language as the target TOS. There is a secondary goal of letting cross-language host-TOS mappings work as well as is reasonable, which means we map all SDL semantics to the semantically equivalent key, but we can't expect 100% coverage for any cross-language mapping.

So, there's not really any possibility here to do something automatically for Japanese keyboards specifically in the symbolic mapping system.

However, there is still the scancode mapping system as before, which you can still use to take control yourself and define the specific mapping you need. Maybe there is a shared collection of useful mapping files that you could contribute it to for others to use?

-- Brad Smith

On Sat, Oct 5, 2024 at 6:05 PM Joel Rees <joel.rees@xxxxxxxxx> wrote:
Okay, I finally had time to dig up my notes in an old blogpost from march 2023:

https://defining-computers.blogspot.com/2023/03/mapping-panasonic-lets-note-japanese.html

This also discusses the problem and the current state of the keyboard
on the older OS and older Hatari release.

I'm afraid I won't have time to pull the updates to Hatari for several
days, but this information may be of use?



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