Re: [hatari-devel] Enhanced keymap support

[ Thread Index | Date Index | More Archives ]

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

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: |

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 (
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:

Which maps fairly closely to PC keyboard US layout (just using different codes):

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 ---


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:

On 3.11.2021 23.04, Vincent Barrilliot wrote:
I gave it a try tonight.


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
With the attached patches you can specify:

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)


Le 01/11/2021 à 00:27, Eero Tamminen a écrit :

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:

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:

(And of course whether there are additional
problems compared to your patch.)

     - Eero

Mail converted by MHonArc 2.6.19+