Re: [hatari-devel] Enhanced keymap support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Enhanced keymap support
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sun, 7 Nov 2021 07:13:12 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1636269194; bh=fskvJir5INmhD+c2+OPQybqwoyYvq4iG1JozA+xhSXs=; h=Date:From:To:Subject:From; b=gDybkzooAAAiNlqx/pEXCSgtgVGCD1/uGUNm0BIIVTQM6hCynNdMptma81YxoxmBy iScGKyU5tahVcLVRb4E8POJc/30GE5GHgJuk6vcRjzS4StEvJoduUZ+ZK48Ni/GK7+ DWPa/5B/XCpFinZPBw2JOGol/rb27eFPuPfVhImguvgl6Vyy5IB2gczDd/GJgDwptu o2EU/Q/9yDY2jlW9tPdm4faZhV62y22aDDLqn4+PchiYh9zvd8CpiV3h/6X7EcQHba mQZsPM7yqdPmbEarAP0/c6oiuEOMIPfFRPiyPwJPWLaBqwN0d+96ROe64fpgWFNIqi zSp5DE9W+Q1sQ==
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