[hatari-devel] Suggestion for enhanced keymap table format

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


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





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