| Re: [hatari-devel] Enhanced keymap support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
This is a multi-part message in MIME format.
Hi,
On 21.11.2021 18.36, Vincent Barrilliot wrote:
I found some time this afternoon so I'm trying to have a look at it.
Thanks for testing! Attached small patches should fix the usability issues.
Rest aren't issues in my code, but things you need to take into account
when doing mappings with SDL and Hatari, regardless of whether you use
your own or my patches.
See details below.
First thing is that decimal stuff is a pain. The links you provide have
the scancodes in hexa, I still don't understand why the heck you demand
decimals in the config file ?
As Hatari key mapping has always used decimals[1], it needs to continue
interpreting values as decimals by default. Otherwise people's existing
keymaps would break when they update their distro to a version having
newer version of Hatari.
But it could accept also hexadecimals when they are prefixed with 0x.
Attached patch does that.
[1] https://hatari.tuxfamily.org/doc/keymap-sample.txt
Also I don't like using symbols (e.g.) "Q" or stuff like that on the
left. It means I have to care about US keyboard layout. > But if I want to
create a keymap, it's because I have another type of keyboard, so why
should I give a shit about US keyboards ? That doesn't make any sense.
I'd rather have something consistent, i.e map scancodes to scancodes
without some other country's keyboard being there like hair in my soup :D
You can always use numeric scancodes, both for SDL and ST key.
For example, for 'ù' I must determine that this key is actually ";" on a
US keyboard. So I'm mapping ";" not "ù". On my keyboard ";" is another
key. How confusing is that ?
The other attached patch should fix that bug, and third one improves
what kind of SDL key names are accepted.
(I didn't notice the bug as I was testing names where SDL scancode &
symbolic name were pointing to same key. For backwards compatibility,
names need to be interpreted as symbolic ones.)
[...]
I didn't get the AltGr to work.
Hatari shortcuts eat most of the AltGr combos:
https://hatari.tuxfamily.org/doc/manual.html#Keyboard_shortcuts_for_the_SDL_GUI
You can bind only keys that Hatari does not use itself.
In the source code, I saw there is
KMOD_ALT as meaning either "KMOD_LALT" and/or "KMOD_RALT". But on a
normal keyboard, LALT is ALT and RALT is AltGr. These really don't have
the same function/meaning, I don't think it's correct to bundle them
under ALT. That is very misleading.
I agree that special handling for left + right key really makes sense
only for SHIFT.
I can remove KMOD_ALT, along with KMOD_CTRL & KMOD_GUI.
(Having those extra left+right defines is actually left-over from your
patch. :-))
Here's the map I tried (I had to look at a US keyboard layout and do
hexa to decimal conversion, so plenty of room for errors).
# Q -> A
Q,16
# W -> Z
W,17
# Z -> E
Z,44
# #
3|SHIFT,43
Although SDL has '#' as symbolic key name, it does not have a scancode
to which it could be matched. See end of this list:
https://wiki.libsdl.org/SDL_Scancode
# {
4|RALT,27|ALT|RSHIFT
AltGr + A is Hatari shortcut for recording video.
After trying that key combo, you probably have largish video file
somewhere...
A,Z,E worked, # and { didn't.
As you see from above, there are some gotchas with the old symbolic name
mapping, and with the new modifier support, which I need to document
before upstreaming these changes.
I was not able to create a mapping for '[' to something. How do you name
these keys ? (side note: using scancode would make things simpler). I
didn't try the ALT_xxx or other things (CTRL, accents etc.) because this
US keyboard indirection confused me and pissed me off.
I think I'll stick to my patch, the parsing sure isn't as good as yours
but it was tons easier for me to create a working map.
Please stick with my patch set still for a while still, it's getting better.
- Eero
PS. Testing is better done by somebody who actually uses the feature
fully, and is different from one who actually wrote the thing. As you
can see, developer can easily miss things...