[GH-ISSUE #1119] Unexpected punctuation characters are emitted when client keyboard layout is not English #896

Open
opened 2026-05-05 07:15:13 -06:00 by gitea-mirror · 1 comment
Owner

Originally created by @MadaraUchiha on GitHub (Apr 6, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1119

Describe the bug
When the target keyboard layout is set to a layout that doesn't match the host (in my case, QWERTY English), characters like , . / ' are emitted instead of the target layout character in that position.

For example, when the keyboard layout is set to Hebrew, pressing the key that in English layout would be , should cause the character ת to be emitted, instead, , is emitted.

To Reproduce

Steps to reproduce the behavior:

  1. Setup a normal session
  2. Enable Hebrew layout for the client
  3. Set client layout to Hebrew
  4. Open any text editor
  5. Press the , key

Expected behavior
The client should type ת onto the text editor.

Actual behavior
The client types , onto the text editor.

Screenshots
N/A

Desktop (please complete the following information):

  • OS: Windows (client: Mac)
  • Barrier version 2.3.3

Additional context

In the case of the Hebrew layout (but probably in other layouts as well), the punctuation keys are laid out differently, for example, to type , in Hebrew, you'd press the key in the QWERTY layout position of ', to type . you'd hit / and so on. Since these keys appear in both layout (albeit in different positions), the original English characters are emitted.

Hebrew characters (i.e. those that don't appear in the English QWERTY layout) work fine, you type m and get צ as expected, for instance.

Attached is an image of a Hebrew keyboard with the keys marked, for illustration
image

Related: #724 #860

Originally created by @MadaraUchiha on GitHub (Apr 6, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1119 **Describe the bug** When the target keyboard layout is set to a layout that doesn't match the host (in my case, QWERTY English), characters like , . / ' are emitted instead of the target layout character in that position. For example, when the keyboard layout is set to Hebrew, pressing the key that in English layout would be `,` should cause the character `ת` to be emitted, instead, `,` is emitted. **To Reproduce** Steps to reproduce the behavior: 1. Setup a normal session 2. Enable Hebrew layout for the client 3. Set client layout to Hebrew 4. Open any text editor 5. Press the `,` key **Expected behavior** The client should type `ת` onto the text editor. **Actual behavior** The client types `,` onto the text editor. **Screenshots** N/A **Desktop (please complete the following information):** - OS: Windows (client: Mac) - Barrier version 2.3.3 **Additional context** In the case of the Hebrew layout (but probably in other layouts as well), the punctuation keys are laid out differently, for example, to type `,` in Hebrew, you'd press the key in the QWERTY layout position of `'`, to type `.` you'd hit `/` and so on. Since these keys appear in both layout (albeit in different positions), the original English characters are emitted. Hebrew characters (i.e. those that don't appear in the English QWERTY layout) work fine, you type `m` and get `צ` as expected, for instance. Attached is an image of a Hebrew keyboard with the keys marked, for illustration ![image](https://user-images.githubusercontent.com/1188951/113709675-74715f00-96eb-11eb-94db-c8f092d3e258.png) Related: #724 #860
Author
Owner

@abutbul commented on GitHub (Aug 11, 2021):

Some info: This does reproduce in Windows 10 but does not in Linux (Ubuntu 20.04 for example).
I have been trying to find keyboard layouts in Windows which will not send , instead of ת but so far none have proven to work.

<!-- gh-comment-id:897066014 --> @abutbul commented on GitHub (Aug 11, 2021): Some info: This does reproduce in Windows 10 but does not in Linux (Ubuntu 20.04 for example). I have been trying to find keyboard layouts in Windows which will not send `,` instead of `ת` but so far none have proven to work.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#896
No description provided.