Re: [hatari-devel] Enhanced keymap support

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


Hi,

Thanks for verifying that the ALT_XXX fix works.

I'll be looking at PortMidi / MIDI stuff this weekend, so I'll have time to look into NOxxx only later.


	- Eero

On 11.12.2021 18.53, Yves Le Berre wrote:
Hello,

1) Guest modifier NOxxx would be interesting if there are many cases
of PC key with modifier xxx mapped to ST key without this modifier.
As there is only one key on french PC keyboard in this situation,
and as this key can be mapped otherwise, i'll let you judge if it's
worth the effort.

2) Applying Patch 0001-Fix-ALT_XXX-scancode-handling.patch
after patching the master (from hatari-master.tar.gz) with patches :

0001-Keymap_LoadRemapFile-refactor-rewrite.patch
0002-Switch-to-using-KeyMapping-struct-and-KeysDown-array.patch
...
0009-Keymap-accept-also-0x-prefixed-hex-values-for-scanco.patch
0010-Fix-improve-keymap-file-SDL-key-name-parsing.patch

give the result :

patching file src/keymap.c
Hunk #1 succeeded at 69 (offset 1 line).
Hunk #2 succeeded at 1037 (offset 104 lines).
Hunk #3 succeeded at 1044 (offset 104 lines).
Hunk #4 succeeded at 1090 (offset 104 lines).

So, i transformed patch 0001-Fix-ALT_XXX-scancode-handling.patch
in 0011-Fix-ALT_XXX-scancode-handling.patch to apply last changes
without offset and have an ordered serie of patches (0001 - 0011).

See attachment.

=> Result is OK : mapping 0x30|RALT to ALT_XXX|249 displays the good character.

Trace :

key down: sym=1073742054 scan=230 mod=0x1200 name='Right Alt'
key down: sym=36 scan=48 mod=0x1200 name='$'
key mapping: f9 (keymap)
key map: sym=0x24 to ST-scan=0xf9
key mod(s): ALT_XXX (0x38) + '2' (0x6e) + '4' (0x6a) + '9' (0x69)
key up: sym=36 scan=48 mod=0x1200 name='$'
key mod(s): ALT_XXX (0x38)
   LSHIFT:0 RSHIFT:0 CTRL:0 ALT:0
key up: sym=1073742054 scan=230 mod=0x1000 name='Right Alt'

Other keys always OK.

Yves

Le 11/12/2021 à 00:54, Eero Tamminen a écrit :
Hi,

On 10.12.2021 18.22, Yves Le Berre wrote:
1) Actually, '§' seems to be the only key on french PC keyboard
with SHIFT PC side and NO SHIFT ST side.

But PC keyboard layout for other countries may have such keys
(modifier PC side and NO modifier ST side).
>
so, could a NO{LSHIFT,RSHIFT,SHIFT,LALT} Guest modifier solve
this case by releasing these keys before pressing down mapped keys ?

Right, it's probably better that user is in full control of that, instead of Hatari automatically trying to infer what modifiers it should (temporarily) release.

It's quite large change, so it's going to take some time, and I'm not sure whether we in the end want that kind of extra complexity to the keymap code...



2) Here is the trace for '¤' (RALT + '$' PC side) mapped with ALT_XXX|249
after starting hatari and emuCON :

key down: sym=1073742054 scan=230 mod=0x1200 name='Right Alt'
key down: sym=36 scan=48 mod=0x1200 name='$'
key mapping: f9 (keymap)
key map: sym=0x24 to ST-scan=0xf9
key mod(s): ALT_XXX (0x38) + '2' (0x6e) + '4' (0x6a) + '9' (0x69)
key up: sym=36 scan=48 mod=0x1200 name='$'
key mod(s): ALT_XXX (0x38)
   LSHIFT:0 RSHIFT:0 CTRL:0 ALT:0
key up: sym=1073742054 scan=230 mod=0x1000 name='Right Alt'

=> No output in hatari window

Attached is a fix for that bug, apply it with "git am <file>" on top of the earlier patches.

Btw. It was actually quite bad, but entertaining bug.  0xf9 was being inserted to IKBD before the ALT_XXX scancodes, which meant that TOS was interpreting ALT_XXX stuff partially as mouse movements [1]...


    - Eero

[1] F9 is IKBD control code for that, see:
https://github.com/emutos/emutos/blob/master/bios/aciavecs.S#L355


and same trace and no output when '¤' keyed again and again...

But as soon as i enter  key 'Left Alt' 2 (two) times, giving this trace :

key down: sym=1073742050 scan=226 mod=0x1100 name='Left Alt'
key mapping: 38 (symbolic)
key map: sym=0x400000e2 to ST-scan=0x38
key up: sym=1073742050 scan=226 mod=0x1000 name='Left Alt'
   LSHIFT:0 RSHIFT:0 CTRL:0 ALT:0
key down: sym=1073742050 scan=226 mod=0x1100 name='Left Alt'
key mapping: 38 (symbolic)
key map: sym=0x400000e2 to ST-scan=0x38
key up: sym=1073742050 scan=226 mod=0x1000 name='Left Alt'
   LSHIFT:0 RSHIFT:0 CTRL:0 ALT:0

=> Then the character appears every time when i enter sucessively '¤' and 'Left Alt'
with the same trace :

key down: sym=1073742054 scan=230 mod=0x1200 name='Right Alt'
key down: sym=36 scan=48 mod=0x1200 name='$'
key mapping: f9 (keymap)
key map: sym=0x24 to ST-scan=0xf9
key mod(s): ALT_XXX (0x38) + '2' (0x6e) + '4' (0x6a) + '9' (0x69)
key up: sym=36 scan=48 mod=0x1200 name='$'
key mod(s): ALT_XXX (0x38)
   LSHIFT:0 RSHIFT:0 CTRL:0 ALT:0
key up: sym=1073742054 scan=230 mod=0x1000 name='Right Alt'
key down: sym=1073742050 scan=226 mod=0x1100 name='Left Alt'
key mapping: 38 (symbolic)
key map: sym=0x400000e2 to ST-scan=0x38
key up: sym=1073742050 scan=226 mod=0x1000 name='Left Alt'
   LSHIFT:0 RSHIFT:0 CTRL:0 ALT:0


3) No other issue detected with the mapping. I repost the mapping configuration
as i changed documentation.

Yves

Le 10/12/2021 à 10:34, Eero Tamminen a écrit :
Hi,

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 :

1)
0x38|SHIFT,0x07
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 :
0x38|SHIFT,ALT_XXX|221
but this disables auto repeat

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


2)
0x30|RALT,ALT_XXX|249
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





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