Re: [hatari-devel] Enhanced keymap support

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


Am Sat, 6 Nov 2021 02:06:35 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 5.11.2021 9.36, Thomas Huth wrote:
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:  
> [...]
> >> Problems:
> >>
> >> 1. Hatari symbolic key handling should have support for all keys in
> >> the Atari ST layout, but it does not.  E.g. several of them do not
> >> have SDL defines.
> >>  
> >>     => key names could be used for mapping those  
> >>
> >> 2. Hatari ignores everything using AltGr, although that's needed
> >> e.g. for @, [] and {} keys on Finnish keyboard.
> >>
> >> 3. mapping some of the keycodes properly requires knowing the
> >> current TOS keyboard layout (US, French etc) to inject correct ST
> >> scancode, but Hatari currently hardcodes US layout.
> >>  
> >>     => Could Hatari infer keyboard layout from TOS version,  
> >> multilanguage TOS header, and NVRAM?  
> > 
> > I think that just doesn't scale. Hatari could guess the right keys
> > in the most common cases, but IIRC there are also Atari programs
> > that change the layout during runtime...  
> 
> I do not think Hatari needs to care what happens after emulation
> starts. If user adds some
> extra keyboard layout change to Atari side,
> it's his/her responsibility then, not Hatari's.
> 
> 
> > Honestly, I think we should get completely rid of the symbolic
> > keyboard mapping nowadays (apart from the loadable keymappings).
> > The symbolic key mapping was mainly included since you could not
> > rely on the scancode layout with SDL1 (e.g. on macOS the layout was
> > completely different there), but with SDL2, we now have the
> > guarantee that the scancode layout it fixed (based on the USB
> > standard, as you've mentioned it).  
> 
> As I mentioned, there are some keys that cannot be
> mapped directly, because the physical layouts of
> PC and Atari keyboards differ a bit (mostly that
> single key Vincent mentioned).
> 
> And there are also keyboards which do not look
> like ST keyboards at all / have a lot less keys.
> 
> => I think symbolic key mapping is still needed  
> for those, but it needs to be significantly
> improved.

Ok, fair point. I just saw that there is also the way to send symbolic
keys via the socket API that you've added in commit 273671a0f ... I
guess that needs to continue to use the symbolic mapping, too?

> > We then should teach users to think of the Atari keyboard layout
> > when typing keys (especially non-letters), and maybe provide some
> > pictures of the Atari keyboard with the keys and corresponding
> > scancodes in the manual.
> > 
> > For people who want to type special characters in a way that rather
> > matches their host keyboard, they then could use the key mapping
> > functionality (which should still be based on symbolic host key
> > names, of course, I don't mean to get rid of these - i.e. the
> > loadable key mapping with symbolic host keys should be done on top
> > of "hard-coded" scancode key mapping that is included in Hatari).
>  >
> > Makes sense?  
> 
> Do you mean removing the user option of
> selecting how keys are mapped?

Yes.

> I'm fine switching the logic to this:
> 
> 1. If no keymap loaded, check keypad (like before)
> 
> 2. If keymap loaded and key matches, use that
> 
> 3. Otherwise try scancode
> 
> 4. If still no match, try symbolic

Agreed, that sounds like a good strategy.

 Thomas



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