GHOST/Wayland event's don't correspond to physical keys #76429

New Issue

Campbell Barton · 2020-05-05T03:48:06+02:00

Campbell Barton commented

2020-05-05 03:48:06 +02:00

With WITH_GHOST_WAYLAND enabled, the GHOST_TKey value from events don't correspond to physical keys.

For all other platforms, it's possible to press a key with Shift held, without this modifier changing to the GHOST_TKey.

So for example you can map a key to Shift+1 without the GHOST_TKey being set to an exclamation value.

Currently with Wayland, the value is translated so holding shift changes the value.

To test:

Enable WITH_GHOST_DEBUG build option.
Run the animation player (for simple testing) blender -a /path/to/image.png
Press the 1. key: 1 is printed to the stdout.
Hold Shift and press 1. key: unknown is printed to the stdout.

With WITH_GHOST_WAYLAND enabled, the `GHOST_TKey` value from events don't correspond to physical keys. For all other platforms, it's possible to press a key with Shift held, without this modifier changing to the `GHOST_TKey`. So for example you can map a key to `Shift+1` without the `GHOST_TKey` being set to an exclamation value. Currently with Wayland, the value is translated so holding shift changes the value. ---- To test: - Enable `WITH_GHOST_DEBUG` build option. - Run the animation player (for simple testing) `blender -a /path/to/image.png` - Press the `1`. `key: 1` is printed to the stdout. - Hold Shift and press `1`. `key: unknown` is printed to the stdout.

Campbell Barton commented

2020-05-05 03:48:06 +02:00

Added subscriber: @ideasman42

Christian Rauch commented

2020-05-05 18:21:18 +02:00

Added subscriber: @christian.rauch

Christian Rauch commented

2020-05-05 18:21:18 +02:00

I can reproduce this. The function xkb_map_gkey receives the XKB_KEY_exclam key, but there is no corresponding GHOST_TKey. It will, therefore, print unhandled key: 33 (XKB_KEY_exclam).

Is GHOST suppose to translate key combinations, e.g. receive Shift + 1 and send !, or should it simply forward hardware keys, e.g. just send Shift and then send 1?

I can reproduce this. The function `xkb_map_gkey` receives the `XKB_KEY_exclam` key, but there is no corresponding `GHOST_TKey`. It will, therefore, print `unhandled key: 33` (`XKB_KEY_exclam`). Is GHOST suppose to translate key combinations, e.g. receive `Shift + 1` and send `!`, or should it simply forward hardware keys, e.g. just send `Shift` and then send `1`?

Campbell Barton commented

2020-05-06 00:54:41 +02:00

should it simply forward hardware keys, e.g. just send Shift and then send 1?

Yes, this is what's expected, there is the ascii and utf8 members which are used at any time where text value needs to be read from the key.

> should it simply forward hardware keys, e.g. just send Shift and then send 1? Yes, this is what's expected, there is the `ascii` and `utf8` members which are used at any time where text value needs to be read from the key.

Christian Rauch commented

2020-05-06 01:04:49 +02:00

In #76429#925038, @ideasman42 wrote:
Yes, this is what's expected, there is the ascii and utf8 members which are used at any time where text value needs to be read from the key.

This is now fixed in https://developer.blender.org/D7632. The modifiers are only used to obtain the utf8 representation. The "raw" key symbol is now mapped without modifiers.

> In #76429#925038, @ideasman42 wrote: > Yes, this is what's expected, there is the `ascii` and `utf8` members which are used at any time where text value needs to be read from the key. This is now fixed in https://developer.blender.org/D7632. The modifiers are only used to obtain the utf8 representation. The "raw" key symbol is now mapped without modifiers.

blender-admin commented

2020-05-06 02:20:32 +02:00

This issue was referenced by 4af9578ab7

This issue was referenced by 4af9578ab794b10ea6742db0dc8d528646beee07

Campbell Barton commented

2020-05-06 02:21:40 +02:00

Changed status from 'Needs Triage' to: 'Resolved'

Campbell Barton closed this issue

2020-05-06 02:21:40 +02:00

Campbell Barton self-assigned this 2020-05-06 02:21:40 +02:00

Campbell Barton referenced this issue

2023-03-16 03:47:11 +01:00