[hatari-devel] Suggestion for enhanced keymap table format

[Vincent Barrilliot <vincent.barrilliot@xxxxxxxxxxx>]

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