#2653 FGData Keyboard.xml issues

[Benedikt Hallinger]

Hi,
while testing some stuff, I noticed that there is something wrong with the keyboard.xml:

1. there are duplicate <commands> assigned</commands>
2. one of the aileron-trim kebyinds was the wrong side
3. The aileron-trim keybinds had issues with the numpad together with numlock active (only a linux issue?)

The attached patch onto de40bf5f94b03dd does fix this.
Apply to fgdata with git am < 0001-Keyboard.xml-fix-trim-reset-with-numlock-on-fix-dupl.patch

[Anonymous]

Hi, thanks for the patch!

I fixed the "2." some time ago, by coincidence. Will try to upstream the fix for "1." as well, the "3." though, would probably take someone with more knowledge that I have, but I'll still see what I can do.

[Benedikt Hallinger]

1. is easy, just add the additional keybinds for 28, 29 and 30

[James Turner]

for 3), the mapping of numeric keypads to codes is a mess I think, and depends on the platform and possible even keyboard layout. I suspect if yo umake a change there, you will fix one thing and break it for another (same issue with Ctrl-M for the map), but of course please do make some experiments and tests: maybe you get lucky!

[Benedikt Hallinger]

I tried it and did not find anything broken.
In fact i have the fix in my testing since i created this ticket :)

[James Turner]

Sure, but did you try macOS and Windows? Or really, ask someone else to check them.

[Benedikt Hallinger]

No, I just checked on linux...

[Anonymous]

I just pushed the fix for "1." [e1c4bc] and also cherry-picked our fixes to "1." and "2." to the stable [e9fda0].

I don't feel competent enough to tell whether the fix for "3." is ok, I'm sorry.

[Gijs]

For issue 3 I think the 'proper' fix is to work on issues [#1956] and [#2726], and make sure that the proper numpad key codes are mapped for all OS. Duplicating the key bindings is bound to give issues when someone makes a change and forgets about the duplicates.