| Re: [hatari-devel] Enhanced keymap support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 7.12.2021 17.46, Yves Le Berre wrote:
Thank you very much.
I am not a developer, but I was interested having a french PC keyboard
giving the right ST key for any key entered on the PC.
I had created a keymap configuration for the patch from Vincent Barrilliot
and noticed that the key for 'à' , 'ù' and '§' could not be obtained
because the XXX sequence of ALT-XXX ST scancodes contained same X
scancode two times and Keymap_KeyDown function called IKBD_PressSTKey
only if
Keyboard.KeyStates[STScanCode] was false.
My patches "inherited" SDL scancode indexing from Vincent's patch, but
do not have this issue because they handle ALT-XXX differently.
I'm still not fully convinced that adding extra SDL scancode indexing
(in addition to earlier ST scancode one) is the right thing to do though.
Extracted from test config for Vincent patch
>
# à 0 @
27|KMOD_CAPS|KMOD_CAPS,0b
27|KMOD_RALT|KMOD_RALT,LSHIFT|03
27|KMOD_LSHIFT|KMOD_LSHIFT,70
27|KMOD_RSHIFT|KMOD_RSHIFT,70
27,ALTERNATE|6d|6f|6f
# ù %
34|KMOD_CAPS|KMOD_CAPS,LSHIFT|06
34|KMOD_LSHIFT|KMOD_LSHIFT,LSHIFT|06
34|KMOD_RSHIFT|KMOD_RSHIFT,LSHIFT|06
34,ALTERNATE|6d|6b|6d
# ! §
38|KMOD_CAPS|KMOD_CAPS,ALTERNATE|6e|6e|6d
38|KMOD_LSHIFT|KMOD_LSHIFT,ALTERNATE|6e|6e|6d
38|KMOD_RSHIFT|KMOD_RSHIFT,ALTERNATE|6e|6e|6d
38,LSHIFT|02
Note that you need to:
* add "0x" in front of all these hex values
* remove the |KMOD_* masks
* Remove KMOD_ prefixes from modifier names
(Make a copy of your file first.)
And this:
> 27|KMOD_LSHIFT|KMOD_LSHIFT,70
> 27|KMOD_RSHIFT|KMOD_RSHIFT,70
Can be done just with this:
27|SHIFT, 70
'à' : ALTERNATE|6d|6f|6f : Alt-133 using num keypad
With my code, this would look like:
à, ALT_XXX|133
'ù' : ALTERNATE|6d|6b|6d : Alt-151 using num keypad > '§' (shift !) : ALTERNATE|6e|6e|6d : Alt-221 using num keypad
NOTE: if you use scancode mapping and French TOS, you do not need keymap
file for these. You already get these letters from '0', '6' keys and
the key that's beside Enter. See the French Atari keyboard layout shown
here:
http://tho-otto.de/keyboards/
I just tested that under Hatari with French TOS v1.04 on ST, and with
1024k EmuTOS version with NVRAM keyboard layout set to French [1] on TT
emulation, and it worked fine...
- Eero
[1] hatari --language fr --layout fr ...
All the other keys (with or without modifiers) could be obtained.
I will compile hatari with latest patches and test it with a configuration
corresponding to the new specification.
Yves
Le 07/12/2021 à 14:39, Eero Tamminen a écrit :
Hi,
Patch series is intended more for review.
Attached is patch with all changes squashed into a single commit, in
case that's easier to apply.
- Eero
On 7.12.2021 15.22, Eero Tamminen wrote:
Hi,
There have been some changes in Hatari which cause
the old patches not to apply any more.
Updated & rebased patch series (that can be
applied on top of the current Hatari Git head)
is attached.
- Eero
On 7.12.2021 10.52, Yves Le Berre wrote:
M. Tamminen,
Could you re-post the "ordered" patches serie of enhanced keymap
support ?
When I tried to apply patches from hatari-devel list to master,
I succeeded with the 8 patches dated 11-11-2021 00:50
but didn't succeed with the 3 patches dated 21-11-2021 21:24.
Are they any other patches to apply ?
Many thanks,
Yves Le Berre
Le 21/11/2021 à 21:24, Eero Tamminen a écrit :
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...