Re: [hatari-devel] Enhanced keymap support

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.

Hi,

Ahem, attached one more fix patch, in case one builds Hatari using 
"Debug" target i.e. with asserts enabled.

(I only just noticed that "RelWithDebInfo" target does not enable asserts.)

Patch is independent of other patches, so can it can be applied before 
or after the other patches.


	- Eero

On 12.12.2021 0.29, Eero Tamminen wrote:
> 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