Re: [hatari-devel] Enhanced keymap support

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi Vincent,

Please keep these mails on hatari-devel as key mapping concerns also 
other Hatair users.

(I accidentally sent the previous patch series directly to you instead 
of the list as result.)

On 4.11.2021 21.33, Vincent Barrilliot wrote:
> 1 About the ALT_XXX thing: it's called ALT_XXX, people use it by 
> pressing ALT with three digits and now these numbers by heart from 
> having to use them. Why expecta hexa number then? I know it could make 
> sense to have the char number there but if feels unnatural (to me at 
> least) for the user creating a keymap. If you want to use hexa you might 
> call the modified ALT_0xYY ! :D

It's explained in the commit messages.

(Because your patch & mappings used hexadecimals, my series also has a 
patch to do the same, to ease your testing.  Just drop that patch to have
numbers parsed as decimals.)


> Sorry I overlooked the instruction, you did tell me it was hexa.
>
> Btw I think the 0x prefix is just noise, have you ever seen scancode 
> displayed in decimal ? I think the previous keymap format didn't require 
> it.

Previous keycode format used decimal. You patch
changed it to hex in keymap parser & trace
messages.


> On any chart, scancodes are in hexa. So we could expect hexa there 
> and have things a little more readable. (granted that is then 
> inconsistent with having ALT_<decimal> ;))

I'm not going to merge hex patch as it would break
compatibility with existing keymap files.


> 2 I don't understand the point about disabling having multiple mappings. 
> Allowing one mapping with modifier only defeats the purpose of making 
> the change in my view because then it doesn't solve the initial problem. 
> Let me give an example: on my French Atari keyboard, the key next just 
> at the right of the Return key, below "Delete" looks like this:
>
> | ~
> # @
>
> That is:
>
> With no modifiers: #
> With ALT: @
> With Shift: |
> With ALT AND SHIFT: ~

These are how you get those keys on Atari. But the issue here is PC 
mappings. [1]


> There are 3 keys in this situation, near the Return key, for many 
> keyboard layouts including Finish (http://tho-otto.de/keyboards/)
[...]
Ok, so that's what you wanted to do.

But IMHO user written keymap files should be needed / reserved just for 
adding few extra / special keys & workarounds.

[1] For mapping whole ST keyboard layout, it would be better to make 
sure Hatari maps things correctly by default.

To recap the problems with that...

Hatari maps either SDL scancodes or keycodes (symbolic host dependent 
character mappings).

--- scancodes ---

Locations for SDL scancodes are based on the USB standard, see 
"Keyboard/Keypad Page" section in USB HID section:
https://www.usb.org/sites/default/files/hut1_22.pdf

Which maps fairly closely to PC keyboard US layout (just using different 
codes):
https://en.wikipedia.org/wiki/Keyboard_layout#/media/File:ANSI_Keyboard_Layout_Diagram_with_Form_Factor.svg

When those PC scancodes are converted to ST scancodes, user should get 
ST key that is in same location on the keyboard, which sidesteps the 
issue of the ST keyboard layout, because all ST keyboards are shaped the 
same.

With scancodes, the problem is host keyboards that do not having keys in 
locations that have keys on ST.  When locations do not match, keys 
cannot be mapped.  For such PC keyboards, one needs to use symbolic mapping.

(Hatari already uses symbolic SDL keycode mapping, if it does not 
recognize the scancode. I do not know whether AlGr combos & dead keys 
belong to that category.)


--- keycodes ---

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?

FYI: I'm going to look at bit into these next.

If you can come up with list of keys missing for French keyboard when 
using symbolic mapping, and to ST scancode they should map on, that 
would help.


> 3 Have you tried my patch ? Everything works well there so should be 
> easy to compare with the rework. Granted the parsing could be more 
> robust, but it otherwise serves its purpose (I've been using it for 
> almost a year now)

Not yet.  I'll do need to check whether it has the same problem (with 
multiple modifier mappings for same PC scancode).


	- Eero

> Side note: why do your messages come across with such short lines ?

Old habit, of fitting text to console sizes for people who haven't 
migrated to GUIs yet. :-)


> On 04/11/2021 00:15, Eero Tamminen wrote:
> > Hi,
> >
> > On 3.11.2021 23.04, Vincent Barrilliot wrote:
> > > I gave it a try tonight.
> >
> > Thanks!
> >
> >
> > > The error messages are useful. However I had the following issues:
> > >
> > > 1 I didn't understand how to do ALT_XXX or it doesn't work (it 
> > > produces the wrong character)
> >
> > For example:
> > # 'B' -> 'µ'
> > 0x05, ALT_XXX|0xe6
> >
> > With the attached version one can use also SDL
> > scancode names for host part, like this:
> > B, ALT_XXX|0xe6
> >
> > ("listkeys" program in Hatari tests/keymap/
> > folder lists all the available scancode names.)
> >
> >
> > > 2 I cannot specify multiple mappings for a same key, with multiple 
> > > identifiers (too bad, that's the whole purpose of the change ^^).
> >
> > If one happens to use multiple mappings with
> > modifiers for the same scancode at the same
> > time, those particular mappings won't work
> > any more (see commit comments).
> >
> > That's why I added to last series a patch to
> > reject such mapping.
> >
> > While I tested that on purpose, it could easily
> > happen also accidentally.  For example if you have
> > mapped same scancode with both left shift & left
> > control, it's possible to accidentally press both
> > modifiers while pressing the corresponding
> > scancode, when meaning to press just one modifier.
> >
> > (You're e.g. in train/bus, or otherwise have
> > shaking hands / keyboard.)
> >
> > I haven't tested it, but I would assume similar
> > case to break those mappings also with your patch?
> >
> >
> > > So not only I cannot do ALT-SHIFT > but e.g. I cannot have a mapping 
> > > with left
> > > shift and another with right shift.  And obviously that also prevents 
> > > having a mapping for CAPSLOCK. Ie the following doesn't work:
> > >
> > > # 3
> > > 20|KMOD_LSHIFT,LSHIFT|04
> > > 20|KMOD_RSHIFT,RSHIFT|04
> > > 20|KMOD_CAPS|KMOD_CAPS,04
> > With the attached patches you can specify:
> > 20|KMOD_SHIFT,LSHIFT|04
> >
> > Instead of needing to specify both left and right
> > shift (KMOD_SHIFT is SDL alias for (KMOD_LSHIFT | KMOD_RSHIFT)).
> >
> > I'm not yet sure what to do with CAPSLOCK, add
> > "SHIFT_AND_CAPS" modifier?
> >
> >
> >     - Eero
> >
> > PS. I think the changes from previous series are
> > limited to patch 007, but it's better to drop
> > commits from previous series, and apply the
> > whole series anew.
> >
> > You can do that with:
> >     git rebase -i origin/master
> >
> > (change "pick" to "drop" for the commits in
> > the old patch series.)
> >
> > After that you can apply the new series:
> >     git am 000*.patch
> >
> > (Just save the new patches to a dir of their own,
> > so that you don't accidentally mix them with
> > other patches, like I've accidentally done few
> > times during the years...)
> >
> > > The error I get is something like
> > >
> > > ERROR: PC/SDL scancode 20 specified already with modifier(s)
> > >
> > >
> > > Vincent
> > >
> > >
> > > Le 01/11/2021 à 00:27, Eero Tamminen a écrit :
> > > > Hi,
> > > >
> > > > Attached is a new version.
> > > >
> > > > It fixes one (embarrasing) crash bug, and adds functionality to 
> > > > prevent SDL key combos that may
> > > > cause trouble.
> > > >
> > > > Still to do: Get back use of SDL key names, for
> > > > backwards compatibility to existing keymaps
> > > > (other than Vincent's).
> > > >
> > > >
> > > >     - Eero
> > > >
> > > > On 27.10.2021 23.36, Eero Tamminen wrote:
> > > > > Hi,
> > > > >
> > > > > Vincent, attached is patch series implementing
> > > > > something similar to your original changes.
> > > > >
> > > > > Could you test (and review) the changes?
> > > > >
> > > > > just save the attached files and apply on top
> > > > > of Hatari master branch with:
> > > > >      git am 0*.patch
> > > > >
> > > > > Keymap files you used with your own patch, should
> > > > > work after you remove modmasks from them.
> > > > >
> > > > >
> > > > > As discussed earlier, it does not support PC mod
> > > > > mask, just unconditionally masks NumLock out
> > > > > when comparing against loaded mappings.
> > > > >
> > > > > Parsing should be more robust (and gives much
> > > > > more detailed error output), and there's special
> > > > > support for ALT-XXX codes.
> > > > >
> > > > > They are specified like this:
> > > > > <PC scancode>[|<modifiers>],ALT_XXX|<scancode>
> > > > >
> > > > > For example, this maps '§' PC key to Atari 'µ'
> > > > > character (230/0x36):
> > > > >      0x35, ALT_XXX|0xe6
> > > > >
> > > > > Because modifiers are now internally handled as
> > > > > bitmasks, they can be specified both for PC and ST
> > > > > side in any order.  Hatari code will always insert
> > > > > them in the same (ST_Modifiers[] array) order.
> > > > >
> > > > >
> > > > > I'm interested whether my version helps with
> > > > > the problem of multiple modifier keys being kept
> > > > > down that you documented here:
> > > > > https://github.com/vinz6751/hatari/blob/d490423ebf28224d4be5a1bbc74addf2723fd5c4/src/keymap.c#L814 
> > > > >
> > > > >
> > > > > (And of course whether there are additional
> > > > > problems compared to your patch.)
> > > > >
> > > > >
> > > > >      - Eero