Re: [hatari-devel] Enhanced keymap support

[ Thread Index | Date Index | More Archives ]


On 8.12.2021 22.16, Yves Le Berre wrote:
In attachment, you'll find the configuration of french PC keyboard mapping.

Thanks, you've documented it nicely!

(I'm considering removing GUI, ALT & CTRL combo PC mod ones though, as shortcuts for pressing both left *and* right one are pretty much useless, whereas SHIFT shortcut for *either* left or right one is very useful.)

Hatari was compiled with patches from M. Tamminen.

It was spawned without any argument (no --language, nor --layout)
and the default configuration uses emutos 1.1.1 (512K rom french language)
and falcon with 14 Mbytes memory.

I tested this keyboard configuration with emuCON (File menu emutos)

All the mapping give the good result except :

gives a '6' ST side when keying '§' PC side.

You already have SHIFT key down, so TOS gives you the shifted '§', which on the French KBD is '6'.

(This is the only mapping you had, where ST key is missing ST-supported modifier specified for PC.)

I'd rather generate key mapping error when ST side is missing ST modifier(s) specified for PC side.

But I guess I could try temporarily injecting IKBD key release for the already pressed ST modifier, and press it again afterwards.

That would need to be done both for press & release, and the extra modifiers state changes on the ST side could mess some ST apps / games KBD state handling, so I'm a bit hesitant about it.

(I think this is something that Vincent's patch could not handle.)

This one may be corrected with :
but this disables auto repeat

I don't think Hatari can do anything to get ALT_XXX shortcuts repeating.

gives no character ST side when keying '¤' PC side
and blocks next keys until alt is keyed PC side
giving the desired ST character (249/0xf9 in atari character table)

Any idea ?

"gives no character" & "blocks next keys" indicates that it's issue with your host windowing / input system. It may be handling that key combo as so called "dead key" i.e. eating / mutating some of the involved key press or release events.

You might see this happening in "--trace keymap" output.

But if SDL cannot map all the related key press & release event, Hatari cannot do anything about that. You just need to map some other key for that character.

Btw. Are above two items *only* issues you've noticed with the new key mapping code?

(If yes, things look pretty good.)

	- Eero


Le 07/12/2021 à 14:22, Eero Tamminen a écrit :

There have been some changes in Hatari which cause
the old patches not to apply any more.

Updated & rebased patch series (that can be
applied on top of the current Hatari Git head)
is attached.

    - Eero

On 7.12.2021 10.52, Yves Le Berre wrote:
M. Tamminen,

Could you re-post the "ordered" patches serie of enhanced keymap support ?

When I tried to apply patches from hatari-devel list to master,
I succeeded with the 8 patches dated 11-11-2021 00:50
but didn't succeed with the 3 patches dated 21-11-2021 21:24.
Are they any other patches to apply ?

Many thanks,

Yves Le Berre

Le 21/11/2021 à 21:24, Eero Tamminen a écrit :

On 21.11.2021 18.36, Vincent Barrilliot wrote:
I found some time this afternoon so I'm trying to have a look at it.

Thanks for testing!  Attached small patches should fix the usability issues.

Rest aren't issues in my code, but things you need to take into account when doing mappings with SDL and Hatari, regardless of whether you use your own or my patches.

See details below.

First thing is that decimal stuff is a pain. The links you provide have the scancodes in hexa, I still don't understand why the heck you demand decimals in the config file ?

As Hatari key mapping has always used decimals[1], it needs to continue interpreting values as decimals by default. Otherwise people's existing keymaps would break when they update their distro to a version having newer version of Hatari.

But it could accept also hexadecimals when they are prefixed with 0x. Attached patch does that.


Also I don't like using symbols (e.g.) "Q" or stuff like that on the left. It means I have to care about US keyboard layout. > But if I want to create a keymap, it's because I have another type of keyboard, so why should I give a shit about US keyboards ? That doesn't make any sense. I'd rather have something consistent, i.e map scancodes to scancodes without some other country's keyboard being there like hair in my soup :D

You can always use numeric scancodes, both for SDL and ST key.

For example, for 'ù' I must determine that this key is actually ";" on a US keyboard. So I'm mapping ";" not "ù". On my keyboard ";" is another key. How confusing is that ?

The other attached patch should fix that bug, and third one improves what kind of SDL key names are accepted.

(I didn't notice the bug as I was testing names where SDL scancode & symbolic name were pointing to same key.  For backwards compatibility, names need to be interpreted as symbolic ones.)

I didn't get the AltGr to work.

Hatari shortcuts eat most of the AltGr combos:

You can bind only keys that Hatari does not use itself.

In the source code, I saw there is KMOD_ALT as meaning either "KMOD_LALT" and/or "KMOD_RALT". But on a normal keyboard, LALT is ALT and RALT is AltGr. These really don't have the same function/meaning, I don't think it's correct to bundle them under ALT. That is very misleading.

I agree that special handling for left + right key really makes sense only for SHIFT.

I can remove KMOD_ALT, along with KMOD_CTRL & KMOD_GUI.

(Having those extra left+right defines is actually left-over from your patch. :-))

Here's the map I tried (I had to look at a US keyboard layout and do hexa to decimal conversion, so plenty of room for errors).

# Q -> A
# W -> Z
# Z -> E
# #

Although SDL has '#' as symbolic key name,  it does not have a scancode to which it could be matched.  See end of this list:

# {

AltGr + A is Hatari shortcut for recording video.

After trying that key combo, you probably have largish video file somewhere...

A,Z,E worked, # and { didn't.

As you see from above, there are some gotchas with the old symbolic name mapping, and with the new modifier support, which I need to document before upstreaming these changes.

I was not able to create a mapping for '[' to something. How do you name these keys ? (side note: using scancode would make things simpler). I didn't try the ALT_xxx or other things (CTRL, accents etc.) because this US keyboard indirection confused me and pissed me off.

I think I'll stick to my patch, the parsing sure isn't as good as yours but it was tons easier for me to create a working map.

Please stick with my patch set still for a while still, it's getting better.

    - Eero

PS. Testing is better done by somebody who actually uses the feature fully, and is different from one who actually wrote the thing.  As you can see, developer can easily miss things...

Mail converted by MHonArc 2.6.19+