hw:[ bind is unusable on AZERTY keyboard on Linux

[ghost]

Original title: "gesture" key (old "taunt") is unusable on azerty keyboards with the default wasd presets

wasd presets binds it it to '[' which is on azerty ALT_GR+5. From what I've seen, the game does not react when this combo is pressed.

I don't think there is any reason to have it moved from 'c' (which is at a common place for all traditional keyboards) to '[' which is both further (close to enter key on qwerty, '5' key on azerty ones) and requires key combination on azerty.

I also think this key is pretty important considering current state, because it's the only way to quickly say something (beacon menu or regular chats are way too slow, and beacon menu is anyway too much focused on signaling things from outside, not stuff like "reloading", "retreating", "follow me", etc)

[slipher]

The bind works fine. hw:[ means the key that is in the location that [ is on the QWERTY layout. For AZERTY, this is ^.

I agree that hw:[ is a questionable choice: there are many unused keys closer to wasd. Issues or pull requests to unvanquished_src.dpkdir welcome.

[ghost]

I just checked anew, and on my keyboard (standard and cheap thing, really, logitech k280e, usb wired) and disposition (setxkbmap fr, debian 10 "buster") it really does not work here, maybe there's another issue behind, since the key keycode 34 (keysym 0xfe52, dead_circumflex) requires hitting another one after to be really used. I suppose using hw:foo should not be affected by the problem, but here it is.

I'm pushing a change back to the old 'hw:c' binding, since it's 1) closer to "directional" keys 2) same key on all traditional layouts I'm aware of (french azerty and qwerty that is) 3) unused 4) the previous default, so people which have played 0.51 or older won't have to change habits.

[slipher]

Default bind change was merged in https://github.com/UnvanquishedAssets/unvanquished_src.dpkdir/pull/55.

I managed to reproduce the hw:[ bug myself now after testing on Linux (it works correctly on Windows). The problem, which can be observed by /in_keyboardDebug 1, is that SDL generates no key event at all for the circumflex key, nor for whichever key is pressed next after it. Like the other issues with the wildly inconsistent keyboard data coming out of SDL, there's probably not much we can do about it.

[ghost]

Just in case, this still happens as of 0.54.0

[slipher]

Maybe I'll close this and make an issue on Daemon listing all of the scenarios where SDL gives us garbage keyboard data.

[slipher]

Still broken with SDL 3.

I read that this happens whenever text input is enabled.