Figure out what to do with keybindings whose characters could be triggered by multiple VKs #3477

Open
opened 2026-01-30 23:22:13 +00:00 by claunia · 6 comments
Owner

Originally created by @ksawerykarwacki on GitHub (Aug 19, 2019).

I tried to map ctrl+shift+| for vertical split but keybinding changed to \(but everything works correctly) additionally i have second backslash button between left shift and z key and using this key combination doesn't work.

Environment

Windows build number: 10.0.18963.0
Windows Terminal version (if applicable): 0.3.2171.0
Keyboard: Logitech K280e

Steps to reproduce

  1. Add binding:
    { "command" : "splitVertical", "keys" : [ "ctrl+shift+|" ] },
  2. Save and close settings
  3. Close Terminal
  4. Open Terminal and settings
  5. Binding looks like this:
    { "command" : "splitVertical", "keys" : [ "ctrl+shift+\\" ] },

No matter what during this steps left backslash never works.

Expected behavior

Keep original symbol and accept left backslash key as trigger.

Originally created by @ksawerykarwacki on GitHub (Aug 19, 2019). I tried to map ctrl+shift+| for vertical split but keybinding changed to \\(but everything works correctly) additionally i have second backslash button between left shift and z key and using this key combination doesn't work. # Environment Windows build number: 10.0.18963.0 Windows Terminal version (if applicable): 0.3.2171.0 Keyboard: Logitech K280e # Steps to reproduce 1. Add binding: `{ "command" : "splitVertical", "keys" : [ "ctrl+shift+|" ] },` 2. Save and close settings 3. Close Terminal 4. Open Terminal and settings 5. Binding looks like this: `{ "command" : "splitVertical", "keys" : [ "ctrl+shift+\\" ] },` No matter what during this steps left backslash never works. # Expected behavior Keep original symbol and accept left backslash key as trigger.
claunia added the Issue-FeatureHelp WantedArea-InputProduct-Terminal labels 2026-01-30 23:22:13 +00:00
Author
Owner

@DHowett-MSFT commented on GitHub (Aug 19, 2019):

Unfortunately, if you typically get | by pressing Shift and the key that says | \, this binding is correct and the keybinding settings are operating as-designed. Since we're asking Windows what your "primary keyboard" has to say on the matter, it's telling us that.

@zadjii-msft Do you know of a Windows tool @ksawerykarwacki could use to figure out what scancode they're getting for their special \ key?

@DHowett-MSFT commented on GitHub (Aug 19, 2019): Unfortunately, if you _typically_ get `|` by pressing <kbd>Shift</kbd> and the key that says <kbd>| \\</kbd>, this binding is correct and the keybinding settings are operating as-designed. Since we're asking Windows what your "primary keyboard" has to say on the matter, it's telling us that. @zadjii-msft Do you know of a Windows tool @ksawerykarwacki could use to figure out what scancode they're getting for their special <kbd>\\</kbd> key?
Author
Owner

@zadjii-msft commented on GitHub (Aug 19, 2019):

I'm not sure there is an inbox tool honestly. There's the echokey tool we use internally on our team, so if you're willing to build from source you could use that to get us the INPUT_RECORD that's generated from that keypress. You'd want to make sure to run that program from a normal console window (not a Terminal window), so we can see the raw output from the OS.

@zadjii-msft commented on GitHub (Aug 19, 2019): I'm not sure there is an inbox tool honestly. There's the [`echokey` tool](https://github.com/microsoft/terminal/blob/master/src/tools/echokey/main.cpp) we use internally on our team, so if you're willing to build from source you could use that to get us the INPUT_RECORD that's generated from that keypress. You'd want to make sure to run that program from a normal console window (not a Terminal window), so we can see the raw output from the OS.
Author
Owner

@ksawerykarwacki commented on GitHub (Aug 20, 2019):

Sorry for the delay but here are the results:

C:\Users\ksawery.karwacki\git\terminal\bin\x64\Debug>ConEchoKey.exe
Start Mode (i/o):(0x 1f7, 0x   3)
New Mode   (i/o):(0x 1f7, 0x   f)
Press ^D to exit
Down: 1 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \  (0x5c) KeyState: 0x20
Down: 0 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \  (0x5c) KeyState: 0x20

And if I press both backslashes there's obviously a difference:

C:\Users\ksawery.karwacki\git\terminal\bin\x64\Debug>ConEchoKey.exe
Start Mode (i/o):(0x 1f7, 0x   3)
New Mode   (i/o):(0x 1f7, 0x   f)
Press ^D to exit
Down: 1 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \  (0x5c) KeyState: 0x20
Down: 0 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \  (0x5c) KeyState: 0x20
Down: 1 Repeat: 1 KeyCode: 0xdc ScanCode: 0x2b Char: \  (0x5c) KeyState: 0x20
Down: 0 Repeat: 1 KeyCode: 0xdc ScanCode: 0x2b Char: \  (0x5c) KeyState: 0x20

I hope that this will help :)

@ksawerykarwacki commented on GitHub (Aug 20, 2019): Sorry for the delay but here are the results: ``` C:\Users\ksawery.karwacki\git\terminal\bin\x64\Debug>ConEchoKey.exe Start Mode (i/o):(0x 1f7, 0x 3) New Mode (i/o):(0x 1f7, 0x f) Press ^D to exit Down: 1 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \ (0x5c) KeyState: 0x20 Down: 0 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \ (0x5c) KeyState: 0x20 ``` And if I press both backslashes there's obviously a difference: ``` C:\Users\ksawery.karwacki\git\terminal\bin\x64\Debug>ConEchoKey.exe Start Mode (i/o):(0x 1f7, 0x 3) New Mode (i/o):(0x 1f7, 0x f) Press ^D to exit Down: 1 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \ (0x5c) KeyState: 0x20 Down: 0 Repeat: 1 KeyCode: 0xe2 ScanCode: 0x56 Char: \ (0x5c) KeyState: 0x20 Down: 1 Repeat: 1 KeyCode: 0xdc ScanCode: 0x2b Char: \ (0x5c) KeyState: 0x20 Down: 0 Repeat: 1 KeyCode: 0xdc ScanCode: 0x2b Char: \ (0x5c) KeyState: 0x20 ``` I hope that this will help :)
Author
Owner

@DHowett-MSFT commented on GitHub (Aug 20, 2019):

Sorry, which backslash is which?

@DHowett-MSFT commented on GitHub (Aug 20, 2019): Sorry, which backslash is which?
Author
Owner

@DHowett-MSFT commented on GitHub (Aug 20, 2019):

Ah, looks like this:

#define VK_OEM_5          0xDC  //  '\|' for US
#define VK_OEM_102        0xE2  //  "<>" or "\|" on RT 102-key kbd.

Unfortunately, keyboard<->character mapping is, almost by definition, lossy. If two keys produce the same exact character, there's no simple way for us to map the character back to the single key that originated it.

Likewise there appears to be no way to ask Windows "What is the full set of scancodes that will produce this character?" If we could do that, we'd just add a mirrored binding internally for every multi-struck character.

Hmm.

@DHowett-MSFT commented on GitHub (Aug 20, 2019): Ah, looks like this: ``` #define VK_OEM_5 0xDC // '\|' for US #define VK_OEM_102 0xE2 // "<>" or "\|" on RT 102-key kbd. ``` Unfortunately, keyboard<->character mapping is, almost by definition, lossy. If two keys produce the same exact character, there's no simple way for us to map the character back to the single key that originated it. Likewise there appears to be no way to ask Windows _"What is the full set of scancodes that will produce this character?"_ If we could do that, we'd just add a mirrored binding internally for every multi-struck character. Hmm.
Author
Owner

@ksawerykarwacki commented on GitHub (Aug 20, 2019):

0x56 is the one between shift and z.

@DHowett-MSFT so there's no way to support this or this key should be handled some custom additional mapping? It is still very useful key for bindigs due to it's location so it would be nice ;)

@ksawerykarwacki commented on GitHub (Aug 20, 2019): 0x56 is the one between shift and z. @DHowett-MSFT so there's no way to support this or this key should be handled some custom additional mapping? It is still very useful key for bindigs due to it's location so it would be nice ;)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#3477