| Re: [hatari-devel] Recent symbolic keyboard mapping change |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 28.8.2023 20.36, Thomas Huth wrote:
On 27/08/2023 21.33, Eero Tamminen wrote:
I noticed that you merged some symbolic key mapping changes. Did you
check the changes against *all* (EmuTOS/MiNT) supported keyboard layouts:
https://tho-otto.de/keyboards/
?
Before you complain, you should maybe have a look at the patches first.
Of course, I reviewed them very carefully first (and if you look at the
PR, you'll see that I also rejected one of the changes).
I was not doubting that, I was just wondering whether you had considered
also the more exotic layouts (as all their differences had been a
surprise for me).
First, SDLK_LEFTBRACKET and SDLK_RIGHTBRACKET... I think I simply got
these wrong in the past when I added that code - as a non-native speaker
I didn't realize that they mean square brackets instead of normal
parantheses. So mapping non-keypad square brackets to the round
parantheses of the keypard does not make too mach sense, does it? Now if
you look at the US english keyboard layout, you can clearly see that the
location of the square brackets there match the scancodes that they are
not mapped to.
And the lack of complaints about those keys in the previous two decades,
was also throwing me off. :-)
The SDLK_BACKQUOTE mapping that we had in Hatari was apparently a hack
for the exotic MacPro keyboard that misses the "insert" key. But that
keyboard misses other keys, too, e.g. there is also no other key that
could produce 0x29 on the ST side as far as I can see. So users of those
reduced keyboards have to create their own mapping anyway, so IMHO it's
better to use a better default for the BACKQUOTE key here for the
majority of users.
OK, thanks for explanations!
Hatari mapping does not conform to any of the real TOS keyboard
layouts, but changing it can break people's existing keymap file
configs. Therefore I'm against changing it until there's a full fix,
making symbolic keymaps to change at run-time based on given TOS
version keyboard layout.
IMHO before we go with any bigger extension of the keyboard mapping
code, we should mostly get rid of the symbolic mapping code in that
file. It's mostly a leftover from the SDL 1.2 era where the scancode
mapping was not working reliably on all host OSes.
IMHO the old symkey mapping is not really problem, it can be removed
afterwards.
Something that maps keys based on their symbols to correct Atari
scancode _for given TOS version / keyboard mapping / country code
setting_, is going to be pretty much completely separate code (based on
my initial look into that few years back).
But that's a bigger change that should maybe rather be done after the
next release. ... by the way, it's been more than a year again since the
last one ... Nicolas, do you have any plans for a new release?
- Eero