Support for binding additional keys #73196

New Issue

Campbell Barton · 2020-01-17T15:11:10+01:00

Campbell Barton commented

2020-01-17 15:11:10 +01:00

There are keys which aren't included in Blender's keymap.

However it doesn't make sense for us to include all possible keys, as there are many which don't make sense (system-wake, calculator, eject, brightness-up, ... see a full list ).

Recently we have added some keys which can be useful.

Application key (used for context menu)
F20-24 (for users to have keyboards with additional F-Keys).

This task is to keep track of other possible additions to the keymap.

Open Topics:

How to handle non US keymaps?
- We could support binding raw keycodes (so we don't need to expand our fixed table of keys to include keys from all keyboard layouts).
- We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference.

There are keys which aren't included in Blender's keymap. However it doesn't make sense for us to include all possible keys, as there are many which don't make sense (system-wake, calculator, eject, brightness-up, ... [see a full list ](https://docs.qmk.fm/#/keycodes)). Recently we have added some keys which can be useful. - Application key (used for context menu) - F20-24 (for users to have keyboards with additional F-Keys). This task is to keep track of other possible additions to the keymap. Open Topics: - How to handle non US keymaps? - We could support binding raw keycodes *(so we don't need to expand our fixed table of keys to include keys from all keyboard layouts).* - We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference.

Campbell Barton commented

2020-01-17 15:11:10 +01:00

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

Campbell Barton commented

2020-01-17 15:11:10 +01:00

Added subscriber: @ideasman42

blender-admin commented

2020-01-17 15:11:10 +01:00

#103358 was marked as duplicate of this issue

Campbell Barton changed title from ~~Support for binding other keys~~ to Support for binding additional keys

2020-01-17 15:12:23 +01:00

Asher commented

2020-01-17 16:04:33 +01:00

Added subscriber: @ThatAsherGuy

Asher commented

2020-01-17 22:27:41 +01:00

For Windows, we're mostly looking at how Blender handles the VK_OEM_1-VK_OEM_8 range when we're talking about layout support, right?

For Windows, we're mostly looking at how Blender handles the `VK_OEM_1`-`VK_OEM_8` range when we're talking about layout support, right?

Debuk commented

2020-02-01 18:41:57 +01:00

Added subscriber: @Debuk

Debuk commented

2020-02-01 19:37:31 +01:00

Open Topics:

How to handle non US keymaps?

We could support binding raw keycodes (so we don't need to expand our fixed table of keys to include keys from all keyboard layouts).

We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference.

@ideasman42 For offering just more unassigned keys to the user both options might be valid. But for shipped keymaps the raw keycodes are fitting much better.

A practical problem for a keymap that would contain both, raw keycodes and logical keycodes, would arise as a keymap might be free of conflicts with an US keyboard layout and have conflicts in another layout due to different overlaps of logical keycodes and raw keycodes based on what layout is chosen.

But for the design of a keymap it would be much simpler by referring to raw keycodes than by mapping something to extended logical keysymbols.
The second option could lead to many multiple assignments to different keys and also would contain the risk of conflicts.

The cleanest approach would be to change the current keymaps to consist mostly raw keycode bindings.
Problematic here would be things like ctrl+z which would be mapped to ctrl+y on a german QWERTZ keyboard if a raw key would be used here
But especially for things like numbers on a french AERTY keyboard layout option 1 would be benefitial

Another problem the second approach is unable to handle is that some keys are the base symbol of a key on a QWERTY. But are keys with Modifiers in other layouts.

So overall just the first option really makes sense to me.

Finally there should be some conversion comfort functionality to get from us layout keys to raw keys and the keymap editor should contain input and display related to a chosen layout.

>Open Topics: > - How to handle non US keymaps? > - We could support binding raw keycodes (so we don't need to expand our fixed table of keys to include keys from all keyboard layouts). > - We could support keyboard layouts, which all include the US keymap, extending on it for keys it doesn't include. This could be selected as a preference. @ideasman42 For offering just more unassigned keys to the user both options might be valid. But for shipped keymaps the raw keycodes are fitting much better. A practical problem for a keymap that would contain both, raw keycodes and logical keycodes, would arise as a keymap might be free of conflicts with an US keyboard layout and have conflicts in another layout due to different overlaps of logical keycodes and raw keycodes based on what layout is chosen. But for the design of a keymap it would be much simpler by referring to raw keycodes than by mapping something to extended logical keysymbols. The second option could lead to many multiple assignments to different keys and also would contain the risk of conflicts. The cleanest approach would be to change the current keymaps to consist mostly raw keycode bindings. Problematic here would be things like ctrl+z which would be mapped to ctrl+y on a german QWERTZ keyboard if a raw key would be used here But especially for things like numbers on a french AERTY keyboard layout option 1 would be benefitial Another problem the second approach is unable to handle is that some keys are the base symbol of a key on a QWERTY. But are keys with Modifiers in other layouts. So overall just the first option really makes sense to me. Finally there should be some conversion comfort functionality to get from us layout keys to raw keys and the keymap editor should contain input and display related to a chosen layout.

Nico Tolvanen commented

2020-06-03 17:09:14 +02:00

Added subscriber: @ThePiklOfTIme

Nico Tolvanen commented

2020-06-03 17:09:14 +02:00

I think supporting keyboard layouts for some common languages would make since, and then just to be on the safe side also support binding to raw key codes by the user. This way you wouldn't have to support literally every single keyboard layout, but still it would be convenient for users. I also hope you'd consider supporting a scandinavian keyboard layout (with keys such as ö,ä,å) since I live here ;), but in all honesty more important might be something like the russian leyout or some asian layouts.

Long Hoang commented

2021-05-26 17:53:17 +02:00

Added subscriber: @htlcnn

Tor Lillqvist commented

2021-10-18 15:23:22 +02:00

Added subscriber: @tml

Tor Lillqvist commented

2021-10-18 15:23:22 +02:00

"raw key codes", ugh, no thanks. Isn't the concept of "key codes" weird legacy that should not be used in modern software? Why not generic support for arbitrary Unicode characters generated by keyboards, plus the usual repertoire of keys that don't correspond to Unicode characters.

Having code in Blender to explicitly handle specific keyboard layouts (like Scandinavian ones mentioned) sounds like working against the system. There will always be more keyboard layouts that somebody will be asking for support for.

But sure, I fully understand that if the current code is based on the idea that there is a small set of possible input keys, making it support arbitrary Unicode characters instead is no small task. Sorry for just whining, sadly I am too occupied in my copious spare time (as the tongue-in-cheek saying goes) with using Blender to have much time to hack on it...

"raw key codes", ugh, no thanks. Isn't the concept of "key codes" weird legacy that should not be used in modern software? Why not generic support for arbitrary Unicode characters generated by keyboards, plus the usual repertoire of keys that don't correspond to Unicode characters. Having code in Blender to explicitly handle specific keyboard layouts (like Scandinavian ones mentioned) sounds like working against the system. There will always be more keyboard layouts that somebody will be asking for support for. But sure, I fully understand that if the current code is based on the idea that there is a small set of possible input keys, making it support arbitrary Unicode characters instead is no small task. Sorry for just whining, sadly I am too occupied in my copious spare time (as the tongue-in-cheek saying goes) with using Blender to have much time to hack on it...

Pierre Schiller commented

2021-10-18 15:59:13 +02:00

Added subscriber: @PierreSchiller

Pierre Schiller commented

2021-10-18 15:59:13 +02:00

I totally appreciate the F13- F24 keys were added. Past 5 weeks ago from this publishing date, I was trying to remap keyboard shortcuts using VIRTUAL keys from MS Powertoys (Keyboard remap) just to get F13-F24 to work in Blender. I found out that AHK (AutoHotkey) scripts can pickup Blender keystrokes, but it was failing to independently identify extra USB connected Numpad. To separate different HID (human interface devices) by ID, I needed to install MacroHID which uses LUA language and CAN effectively discern between an extra USB Numpad keypress from the regular typing keyboard Numpad Keypress.

The issue is that even though I manage to identify whether a keystroke came from the extra USB Numpad or the regular Typing Numpad (i.e. Numpad 1), the command triggered but then the camera will also be on FRONT ORTHOGRAPHIC view. The only way around this was to unbind all Numpad keys (at least for the 3D>General>Viewport category) and re-bind them to something like F13+Shift+1 = Front view.
That way the extra USB Numpad can send specific F-number key combinations re-wired to the new shortcuts I needed, and the regular typing keyboard Numpad was still able to call out other functions as well.

The focus of the above case is that Blender could possibly identify HID by ID and let the user assign his own shortcuts to that device. Blender is able to recognize VR hardware, CPU, GPU, I think it would be so helpful to identify extra USB keyboards / numpads and assign them to custom commands, presets or assets immediately into scene.

I totally appreciate the F13- F24 keys were added. Past 5 weeks ago from this publishing date, I was trying to remap keyboard shortcuts using VIRTUAL keys from MS Powertoys (Keyboard remap) just to get F13-F24 to work in Blender. I found out that AHK (AutoHotkey) scripts can pickup Blender keystrokes, but it was failing to independently identify extra USB connected Numpad. To separate different HID (human interface devices) by ID, I needed to install MacroHID which uses LUA language and CAN effectively discern between an extra USB Numpad keypress from the regular typing keyboard Numpad Keypress. The issue is that even though I manage to identify whether a keystroke came from the extra USB Numpad or the regular Typing Numpad (i.e. Numpad 1), the command triggered but then the camera will also be on FRONT ORTHOGRAPHIC view. The only way around this was to unbind all Numpad keys (at least for the 3D>General>Viewport category) and re-bind them to something like F13+Shift+1 = Front view. That way the extra USB Numpad can send specific F-number key combinations re-wired to the new shortcuts I needed, and the regular typing keyboard Numpad was still able to call out other functions as well. The focus of the above case is that Blender could possibly identify HID by ID and let the user assign his own shortcuts to that device. Blender is able to recognize VR hardware, CPU, GPU, I think it would be so helpful to identify extra USB keyboards / numpads and assign them to custom commands, presets or assets immediately into scene.

Yevgeny Makarov commented

2021-11-14 10:32:15 +01:00

Recently we have added some keys which can be useful.
F20-24 (for users to have keyboards with additional F-Keys).

Well, F20-24 are considered useful, although I don't even know where to find such keyboards and I have doubts that it is convenient to press F24.
But at the same time, the "Section" key, which is on every Mac with an international keyboard, and is located to the left of 1, is not considered such...

Judging by the number of reports that users leave, this should have a higher priority.
At least some decision should be made here on how it should work and perhaps there will be a volunteer who will help to implement it.

Damn it, I understand if some exotic device is not supported, but just a keyboard with a non-English layout?

> Recently we have added some keys which can be useful. > F20-24 (for users to have keyboards with additional F-Keys). Well, F20-24 are considered useful, although I don't even know where to find such keyboards and I have doubts that it is convenient to press F24. But at the same time, the "Section" key, which is on every Mac with an international keyboard, and is located to the left of 1, is not considered such... Judging by the number of reports that users leave, this should have a higher priority. At least some decision should be made here on how it should work and perhaps there will be a volunteer who will help to implement it. Damn it, I understand if some exotic device is not supported, but just a keyboard with a non-English layout?

Omar Emara commented

2022-12-20 10:18:30 +01:00

Added subscribers: @fmy, @OmarEmaraDev

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Support for binding additional keys #73196