Re: [hatari-devel] Suggestion for enhanced keymap table format

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Thomas is probably best person to comment on this,
but until we've removed support for SDL v1, these
kind of changes should support both SDL v1 and v2.

Regardless of that, could you send your PoC changes as patch to list?

(Just the relevant changes, no extra white space
changes etc.)


Keymap file format change isn't necessarily much
of a problem, if you could provide also (shell or
python) script that can convert between the
formats.

	- Eero

On 10/31/20 12:28 AM, Vincent Barrilliot wrote:
> Dear Hatari developers,
>
> I am new to Hatari development. I am French, 43 and I also follow EmuTOS 
> and FreeMiNT development although I listen and learn at the moment.
>
> You have been doing a fantastic job with Hatari, thank you for such a 
> great piece of software !
>
> As a French keyboard user, I am suffering from the inconvenience of the 
> "alt-shift" keys which are not well supported currently, and I have 
> decided to do something about it.
>
> I have made a proof of concept where I modified keymap.c with the 
> following improvement:
>
> The keymap is now an array of KeyMappings structs which have the 
> SDL_keysym on one hand, and a list of ST scancodes on the other hand.
>
> By pressing AltGr-' on my French PC keyboard, Hatari sends scancodes of 
> shift-alt-# to its "ikbd", and an opening curly brace is correctly 
> output in e.g. STeno or EmuCON.
>
> So this works and should enable to bind any key+modifiers from the PC to 
> any sequence of scancodes on the ST side, solving that old problem for 
> good.
>
> Now I need to be able to make that configurable and enhance the format 
> of the keymap configuration file to support this and I would your advice 
> for this.
>
> Obviously I could make something that works with scancodes numbers only, 
> but it would break the current "symbolic" mapping which although not 
> perfect, is easy to use and understand.
>
> I've had the following ideas:
>
> 1 Use some "section" delimiter in the config file so to indicate to the 
> parser how to interpret following the lines.
>
> SYMBOLIC
>
> Y,44
>
> Z,21
>
> SCANCODE
>
> 21|200,2a|38|1a
>
> (we could also allow usage of modifier names or ST modifier names to 
> make things more friendly, ie 21|KMOD_RALT,LSHIFT|ALTERNATE|1a)
>
> 2 Introduce some prefix to indicate to the parser what is we're 
> describing. Eg s for symbolic, r for raw (scancode).
>
> sY,44
>
> r21|KMOD_RALT,LSHIFT|ALTERNATE|r1a
>
> But that would break backward compatibility with exiting keymaps...
>
>
> None of that sounds great... By default I'd go with the scancode because 
> it's the most robust. There is only a handful of keys to "override" 
> anyway so we wouldn't compete with /etc/termcap's complexity. We can 
> also ship a few standard keymaps. But then what do we do with existing 
> user keymaps...?
>
> Thanks for any idea!
>
>
> Vincent B