[PR #910] [MERGED] Fixed processing of non-ASCII symbols missing in CP_THREAD_ACP but present in current KB layout #1717

New issue

Closed

opened 2026-05-05 08:00:11 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 08:00:11 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/debauchee/barrier/pull/910
Author: @eugenegff
Created: 10/13/2020
Status: ✅ Merged
Merged: 12/30/2020
Merged by: @p12tic

Base: master ← Head: fix/non-ascii-kb-layouts

📝 Commits (1)

09e1dbd platform: Fixed processing of non-ASCII symbols

📊 Changes

3 files changed (+39 additions, -56 deletions)

View changed files

📝 src/lib/platform/MSWindowsHook.cpp (+26 -26)
📝 src/lib/platform/MSWindowsKeyState.cpp (+6 -23)
📝 src/lib/platform/MSWindowsScreen.cpp (+7 -7)

📄 Description

Hi there, my name is Eugene Golushkov, I had problems with Barrier and being the programmer decided to contribute fix.

I'm Ukrainian, this language uses https://en.wikipedia.org/wiki/Cyrillic_script, Unicode range 0x400 - 0x4FF, Windows cp1251

My setup consists of

Windows 10 PC, Barrier Server, ENG + UKR keyboard layouts.
macOS Catalina, Barrier Client, ENG + UKR keyboard layouts.
Windows 10 Tablet, Barrier Client, ENG + UKR keyboard layouts.

Problem description:
When current keyboard layout is ENG everything works like a charm. But if I move mouse cursor to clients (2),(3) having UKR keyboard layout selected on win server (1), then win client (3) ignores key strokes, and macos client (2) enters Latin characters with diacritics instead.

Expected result:

Produce Cyrillic characters on clients if possible
Or fallback to English characters
But never produce Latin characters with diacritics that are absent in both English and Ukrainian

Solution:
I enabled Debug1 log level on macos client (2) and pressed 'A' key that is near CapsLock, in ENG KB layout. Got expected log:
DEBUG1: recv key down id=0x00000061, mask=0x2000, button=0x001e
then I switched to UKR layout on (1) and pressed the same physical key, that was expected to produce U+0444 CYRILLIC SMALL LETTER EF, but got such log:
DEBUG1: recv key down id=0x000000f4, mask=0x2000, button=0x001e
where 0xF4 is code for CYRILLIC SMALL LETTER EF in Windows ANSI codepage cp1251.

It became obvious that Barrier was not able to restore unicode char from ANSI, probably because CP_THREAD_ACP that it tried to use for this purpose is not in any way connected to current HKL. This was even as (1) had "Current language for non-Unicode programs" = Ukrainian. The fix was easy - keyboard driver already produces UTF16 chars that could be obtained by ToUnicode function. ToAscii is actually just simple wrapper around ToUnicode that further converts UTF16 chars to ANSI, and by avoiding this unnecessary step we will fix the problem. Barrier inter-machine protocol is Unicode based (KeyID).

Results:

I built Barrier with fix, without GUI and installer, and substituted binaries into existing Barrier setup. Everything still works on clients (2), (3) with ENG keyboard layout selected on win server (1)
windows client (3) that previously ignored keystrokes - now enters Cyrillic characters with UKR keyboard layout selected on win server (1), and language indicator on (3) synchronizes with language indicator on (1) after the first pressed key.
macos client that previously entered Latin characters with diacritics - now see in log proper key down id 0x00000444, but entered proper English chars - there are still space for improvement, quite possibly I will look there later.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/debauchee/barrier/pull/910 **Author:** [@eugenegff](https://github.com/eugenegff) **Created:** 10/13/2020 **Status:** ✅ Merged **Merged:** 12/30/2020 **Merged by:** [@p12tic](https://github.com/p12tic) **Base:** `master` ← **Head:** `fix/non-ascii-kb-layouts` --- ### 📝 Commits (1) - [`09e1dbd`](https://github.com/debauchee/barrier/commit/09e1dbdf8484c8ed18fa715bdf4ef303ff854591) platform: Fixed processing of non-ASCII symbols ### 📊 Changes **3 files changed** (+39 additions, -56 deletions) <details> <summary>View changed files</summary> 📝 `src/lib/platform/MSWindowsHook.cpp` (+26 -26) 📝 `src/lib/platform/MSWindowsKeyState.cpp` (+6 -23) 📝 `src/lib/platform/MSWindowsScreen.cpp` (+7 -7) </details> ### 📄 Description Hi there, my name is Eugene Golushkov, I had problems with Barrier and being the programmer decided to contribute fix. I'm Ukrainian, this language uses https://en.wikipedia.org/wiki/Cyrillic_script, Unicode range 0x400 - 0x4FF, Windows cp1251 My setup consists of 1. Windows 10 PC, Barrier Server, ENG + UKR keyboard layouts. 2. macOS Catalina, Barrier Client, ENG + UKR keyboard layouts. 3. Windows 10 Tablet, Barrier Client, ENG + UKR keyboard layouts. Problem description: When current keyboard layout is ENG everything works like a charm. But if I move mouse cursor to clients (2),(3) having UKR keyboard layout selected on win server (1), then win client (3) ignores key strokes, and macos client (2) enters Latin characters with diacritics instead. Expected result: 1. Produce Cyrillic characters on clients if possible 2. Or fallback to English characters 3. But never produce Latin characters with diacritics that are absent in both English and Ukrainian Solution: I enabled Debug1 log level on macos client (2) and pressed 'A' key that is near CapsLock, in ENG KB layout. Got expected log: DEBUG1: recv key down id=0x00000061, mask=0x2000, button=0x001e then I switched to UKR layout on (1) and pressed the same physical key, that was expected to produce U+0444 CYRILLIC SMALL LETTER EF, but got such log: DEBUG1: recv key down id=0x000000f4, mask=0x2000, button=0x001e where 0xF4 is code for CYRILLIC SMALL LETTER EF in Windows ANSI codepage cp1251. It became obvious that Barrier was not able to restore unicode char from ANSI, probably because CP_THREAD_ACP that it tried to use for this purpose is not in any way connected to current HKL. This was even as (1) had "Current language for non-Unicode programs" = Ukrainian. The fix was easy - keyboard driver already produces UTF16 chars that could be obtained by ToUnicode function. ToAscii is actually just simple wrapper around ToUnicode that further converts UTF16 chars to ANSI, and by avoiding this unnecessary step we will fix the problem. Barrier inter-machine protocol is Unicode based (KeyID). Results: 1. I built Barrier with fix, without GUI and installer, and substituted binaries into existing Barrier setup. Everything still works on clients (2), (3) with ENG keyboard layout selected on win server (1) 2. windows client (3) that previously ignored keystrokes - now enters Cyrillic characters with UKR keyboard layout selected on win server (1), and language indicator on (3) synchronizes with language indicator on (1) after the first pressed key. 3. macos client that previously entered Latin characters with diacritics - now see in log proper key down id 0x00000444, but entered proper English chars - there are still space for improvement, quite possibly I will look there later. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>