|Re: [hatari-devel] Suggestion for enhanced keymap table format|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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
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
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
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
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.
(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).
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
Thanks for any idea!