Fix Ctrl keycodes

[M374LX]

Fixes #7189.

[Frosty-J]

Sorry, I was too quick to react. It's probably okay, so long as everyone's using the constants rather than hardcoding the values. Just add something in the CHANGES file such as [BREAKING CHANGE] CONTROL_LEFT and CONTROL_RIGHT are now keycodes 113 and 114 for all platforms, to match Android so it's less likely to catch someone out by surprise.

I checked these files, so it looks okay for all platforms:

• DefaultLwjgl3Input
• DefaultLwjglInput
• DefaultIOSInput
• DefaultIOSInput (MetalANGLE)
• DefaultGwtInput

[mgsx-dev]

It's probably okay, so long as everyone's using the constants rather than hardcoding the values.

Could be a big problem for users that store key mapping in a file. Maybe having a mapping for these keys in DefaultAndroidInput would be better no?

[Frosty-J]

Depends how they store their mapping. If it's just the raw values and not a human-readable format, it's a minor inconvenience.

// Psuedocode of sorts for updating outdated key mapping
if (userKey == 129) userKey = Input.Keys.CONTROL_LEFT;
if (userKey == 130) userKey = Input.Keys.CONTROL_RIGHT;

Remapping in DefaultAndroidInput or somewhere would indeed be an option. I'd rather libGDX stick to some sort of standard, as it seems unnecessarily complicated not to.

[M374LX]

We could add a note about storing key mapping in a file to CHANGES.

An alternative is to keep the current keycodes and add a check like this one to DefaultAndroidInput's onKey() method:

int keycode = e.getKeyCode();

if (keycode == 113) {
    keycode = Input.Keys.CONTROL_LEFT; //129
} else if (keycode == 114) {
    keycode = Input.Keys.CONTROL_RIGHT; //130
}

[MrStahlfelge]

If someone maps the key values by configuration, it should be no problem as the real key values were saved.

[Berstanio]

If someone maps the key values by configuration, it should be no problem as the real key values were saved.

I don't quite understand, how this does not break. If I write 129 as a key mapping in a config file and compare that "old" value for CONTROL_LEFT (129) to a key press event, which has the "new" value for CONTROL_LEFT (113), it will not work, right?
So I would need to write migration logic, as I understand it?

[MrStahlfelge]

Usually you write custom key mapping configuration in a way that users press the keys they want. The bug here is that a constant in our framework has the wrong value. Independent from that, if a user presses a key, the system gives the real value and not a wrong value from our framework.
After we fix the wrong value in our framework, if a user presses a key, the system still gives the correct value. So no migration is needed.

If you really wrote the old value 129 in your mapping file, the mapping just did not work before the change and after the change. At least it did not work when the user pressed Ctrl key

[Berstanio]

How I understand it is the following:
The user presses a key and the backend specific key code gets converted to a gdx keycode, which gets propagated to the listeners, like here:

libgdx/backends/gdx-backend-lwjgl3/src/com/badlogic/gdx/backends/lwjgl3/DefaultLwjgl3Input.java

Lines 137 to 138 in 75612da

	key = getGdxKeyCode(key);
	eventQueue.keyDown(key, System.nanoTime());

I then receive the gdx keycode the user pressed for the custom mapping and write it to a file. After that I can compare the saved gdx keycode to the pressed gdx keycode. If now the pressed gdx keycode changes, this wont work anymore in my understanding.

I can test this pr someday later.

If you really wrote the old value 129 in your mapping file, the mapping just did not work before the change and after the change. At least it did not work when the user pressed Ctrl key

I just tested it, mapping the Ctrl key works on desktop.

[MrStahlfelge]

My fault, I only thought about Android and forgot that all other platforms use the constants for internal mapping. Sorry.

[M374LX]

In fact, I did not think about the key mappings being saved in a file while preparing this PR.

On platforms other than Android, there might be problems when saving the old values (129 and 130) from an old libGDX version, upgrading libGDX, and then loading the values, which will no longer correspond to those of Keys.CONTROL_LEFT and Keys.CONTROL_RIGHT.

Does anyone prefer the approach suggested here? #7191 (comment)