mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #217] Missing ÅÄÖ on swedish keyboard #176
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#176
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ScuttleSE on GitHub (Jan 2, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/217
Operating Systems
Server: Windows 10 1803
Client: Ubuntu 18.10
Barrier Version
Server: 2.1.0
Client 2.2.0
Swedish keys ÅÄÖ does not work on client. Everything else works as expected, just these three letters that are non-working.
Debug output on server when hitting buttons:
[2019-01-02T22:12:33] DEBUG2: wrote 104 bytes [2019-01-02T22:12:33] DEBUG1: hook: 0x000000dd 0x001a0001 [2019-01-02T22:12:33] DEBUG1: hook: 0x0601e5dd 0x001a0001 [2019-01-02T22:12:33] DEBUG1: hook: 0x0700e5dd 0x001a0001 [2019-01-02T22:12:33] DEBUG1: event: Key char=229, vk=0xdd, nagr=0, lParam=0x001a0001 [2019-01-02T22:12:33] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:33] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:33] DEBUG1: onKeyDown id=65533 mask=0x2000 button=0x001a [2019-01-02T22:12:33] DEBUG1: hook: 0x000000dd 0x801a0001 [2019-01-02T22:12:33] DEBUG1: hook: 0x0601e5dd 0x801a0001 [2019-01-02T22:12:33] DEBUG1: hook: 0x0700e5dd 0x801a0001 [2019-01-02T22:12:33] DEBUG1: event: Key char=229, vk=0xdd, nagr=0, lParam=0x801a0001 [2019-01-02T22:12:33] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:33] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:33] DEBUG1: onKeyUp id=65533 mask=0x2000 button=0x001a [2019-01-02T22:12:34] DEBUG1: hook: 0x000000de 0x00280001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0601e4de 0x00280001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0700e4de 0x00280001 [2019-01-02T22:12:34] DEBUG1: event: Key char=228, vk=0xde, nagr=0, lParam=0x00280001 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: onKeyDown id=65533 mask=0x2000 button=0x0028 [2019-01-02T22:12:34] DEBUG1: hook: 0x000000de 0x80280001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0601e4de 0x80280001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0700e4de 0x80280001 [2019-01-02T22:12:34] DEBUG1: event: Key char=228, vk=0xde, nagr=0, lParam=0x80280001 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: onKeyUp id=65533 mask=0x2000 button=0x0028 [2019-01-02T22:12:34] DEBUG1: hook: 0x000000c0 0x00270001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0601f6c0 0x00270001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0700f6c0 0x00270001 [2019-01-02T22:12:34] DEBUG1: event: Key char=246, vk=0xc0, nagr=0, lParam=0x00270001 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: onKeyDown id=65533 mask=0x2000 button=0x0027 [2019-01-02T22:12:34] DEBUG1: hook: 0x000000c0 0x80270001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0601f6c0 0x80270001 [2019-01-02T22:12:34] DEBUG1: hook: 0x0700f6c0 0x80270001 [2019-01-02T22:12:34] DEBUG1: event: Key char=246, vk=0xc0, nagr=0, lParam=0x80270001 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: onKeyUp id=65533 mask=0x2000 button=0x0027 [2019-01-02T22:12:34] DEBUG1: hook: 0x00000044 0x00200001 [2019-01-02T22:12:34] DEBUG1: hook: 0x06016444 0x00200001 [2019-01-02T22:12:34] DEBUG1: hook: 0x07006444 0x00200001 [2019-01-02T22:12:34] DEBUG1: event: Key char=100, vk=0x44, nagr=0, lParam=0x00200001 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: onKeyDown id=100 mask=0x2000 button=0x0020 [2019-01-02T22:12:34] DEBUG1: hook: 0x00000044 0x80200001 [2019-01-02T22:12:34] DEBUG1: hook: 0x06016444 0x80200001 [2019-01-02T22:12:34] DEBUG1: hook: 0x07006444 0x80200001 [2019-01-02T22:12:34] DEBUG1: event: Key char=100, vk=0x44, nagr=0, lParam=0x80200001 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: new mask: 0x2000 [2019-01-02T22:12:34] DEBUG1: onKeyUp id=100 mask=0x2000 button=0x0020 [2019-01-02T22:12:36] DEBUG2: writef(CALV) [2019-01-02T22:12:36] DEBUG2: wrote 4 bytesI hit åäöd
@Svahnen commented on GitHub (Feb 21, 2019):
I have the same thing (win host, arch client), i use "setxkbmap -device 5 se" to get all the other keys to work, but åäö still does nothing, they dont even register anything in "xev"
@Svahnen commented on GitHub (Feb 21, 2019):
I think this issue have been around for a while
https://github.com/symless/synergy-core/issues/5850
but its NOT the same as https://github.com/symless/synergy-core/issues/4280
Even tho they closed the old åäö issue due to thinking them the same, this senario is different because all other keys are mapped correctly and both server and client uses swe, if i switch client and server the other way around (arch host, win client) it works, i think that "Virtual core XTEST keyboard" only recognices us keys, and we can successfully remap those to where they are suposed to be on the swedish keyboard, but the "extra" keys (åäö) are just plain missing.
@Svahnen commented on GitHub (Feb 21, 2019):
found a termporary workaround, but it breaks åäö on the server while the client is connected, at least it works somewhat, i will probably remap the shortcuts to something else that gets triggered at the same time as my normal åäö by ahk to restore functionality on both client and server at the same time.
All i did was map åäö to be sent to the client when pressing the hotkeys (åäö)
EDIT: This is what i came up with when using AHK
SC01A::
Send, {ASC 134}
Return
SC028::
Send, {ASC 132}
Return
SC027::
Send, {ASC 148}
Return
^SC01A::
Send, {ASC 143}
Return
^SC028::
Send, {ASC 142}
Return
^SC027::
Send, {ASC 153}
Return
I did it this way cus it seems AHK cant capture key events when client have control, but this overrides barrier and still sends åäö to the server. (Oh and sry i could not get capital letters to work on client, i rly tried.)
@mnemonic47 commented on GitHub (Apr 11, 2019):
Thank you @Svahnen, it's an ok temporary solution, but not feasible in the long run. I'm actually pretty darn upset with developers of Synergy, i heard only good things, only read good things, looked amazing, bought it. Instantly disappointed because "ÅÄÖ" does not work when remote controlling computers with Swedish keyboard layouts. And i've seen this issue around for a year now..
I have tried all possible "fixes" and none works completely. Tried both version 1 and the Version 2 Beta. Doesn't matter if it's two swedish pc's with exact same set-up, ÅÄÖ does not work from one to another.
Developers; Fix this, pretty please!
@matrixes commented on GitHub (May 17, 2019):
Yeah, this isn't stellar performance for something that I believe is mainly supposed to be able to communicate mouse movement and keystrokes across computers.
I've "lost" 5 keys on my client because these are seemingly not supported by the software (not that that is stated anywhere).
I wouldn't be upset if it would have been stated that only US layouts are supported, but without that disclaimer you're getting fooled into believing it "just works".
@henryford commented on GitHub (May 20, 2019):
This is also true for German Umlauts (ä, ö, ü, ß) - they do not work on the client.
@hliasa commented on GitHub (May 31, 2019):
Greek also (ά, ύ, ί, ό, ώ, ή, etc).
Arch host - win10 client
@AstralStorm commented on GitHub (Jun 18, 2019):
See issue: https://github.com/symless/synergy-core/issues/6512
Affects Barrier as well and the same workaround can be used if you accept en-US as the "first" keyboard layout.
@mnemonic47 commented on GitHub (Jul 22, 2019):
Ok, interesting. Although if that is a working workaround. Is there any actual progress made in the development of the software to prevent this bugs yet?
@p12tic commented on GitHub (Jul 25, 2019):
I believe no. Barrier is developed by a team of volunteers, fixes for bugs are not guaranteed to be done in timely manner.
@AndreasGrip commented on GitHub (Sep 28, 2019):
Server: Windows 10 1903
Client: Windows 10 1903
Barrier Version
Server: 2.3.1
Client 2.3.1
In the hope of help the developers the debug log looks like this. when pressing åäö
My best guess is that it's utf8/16 gone bad.
And while a would prefer it to "simply work", PLEASE PLEASE PLEASE developer, as a workaround make it possible to make custom mappings for id+mask+button so I could map
id=0x0000fffd, mask=0x2000, button=0x0027
to ö.
I figure it should be fairly easy to create as I assume there is already some mapping function available.
the buttons åäö makes upp about 0.1-5% of typed chars in languages like swedish so it's a real pain to not have them when typing in native languages.
@AndreasGrip commented on GitHub (Oct 27, 2019):
It's not related to the problem but a workaround that I currently using.
Using a Razer Ornata (gaming keyboard) that allows scripts to be mapped to any keys.
So I have created 3 profiles (changed using fn + 0/1/2
Profile 0 is normal keyboard
Profile 1 I have mapped
å = alt + 0 + 2 + 2 + 9 keypress (generating å)
ä = alt + 0 + 2 + 2 + 8 keypress (generating ä)
ö = alt + 0 + 2 + 4 + 6 keypress (generating ö)
Profile 2 I have mapped
å = alt + 0 + 1 + 9 + 7 keypress (generating Å)
ä = alt + 0 + 1 + 9 + 6 keypress (generating Ä)
ö = alt + 0 + 2 + 1 + 4 keypress (generating Ö)
It's not a perfect solution but it's by far the best solution I figued out so far. Usually I use Profile1, not having access to capital letters is acceptable most of the time.
It should be possible to do the same with for isntance autohotkey but I didn't managed to get it to work :(
@Nitrooo commented on GitHub (Nov 23, 2019):
Server: Linux Mint, Italian layout, running version 2.3.2
Client: Linux Manjaro, Italian layout, running version 2.3.2
è, ò, à, ù keys not working.
@AZeroEight commented on GitHub (Dec 2, 2019):
I just got a new system with windows 10 installed and run into this issue but all used to work fine on the old one (German Umlauts in my case)...
...I compared the settings and found the culprid in my case. It is part of the administrative regional settings / system locale. There is a checkbox for Beta UTF-8 support which was checked on the new system - unchecking and restarting Barrier solved the issue for me.
@cmtec commented on GitHub (May 5, 2020):
Installing Swedish language pack (Microsoft) and activated it on the server side solved this for me.
Server: Win10
Client1: Win10
Client2: Arch Linux
@AndreasGrip commented on GitHub (May 11, 2020):
I'll be... I'm quite confident that I tried that already about a year ago in vain, but now it worked!!
@cmtec Thanks ALOT for taking the time to write this comment, I have been struggling with this for more than a year and this solved the problem (even if it's a bit inconvenient to have windows in swedish on one mashine it ALOT better than the workarounds!)
@carlesoriol commented on GitHub (May 14, 2020):
This is a blocking feature. You cannot use a virtual keyboard if misses basic characters accents are important but also |@#...
Server: ubuntu 20.04
Client: ubuntu 20.04
Server: 2.3.2-Release-00000000
Client: 2.3.2-Release-00000000
@shymega commented on GitHub (Aug 31, 2020):
Related to #860.
@MrClue commented on GitHub (Sep 22, 2020):
This post helped me fix the problem with missing keys (using nordic keyboard layout):
https://github.com/symless/synergy-core/issues/6512
@eugenegff commented on GitHub (Oct 14, 2020):
The ultimate fix for wrong UTF16 char passed as KeyID is in pull request https://github.com/debauchee/barrier/pull/910 The solution is to take UTF16 char produced by current keyboard layout on win host directly, without any conversion to some flavor of ANSI code page and back to UTF16, that obviously works unreliable in so many cases.
@p12tic commented on GitHub (Jan 10, 2021):
I'm assuming that this bug is fixed by #910 and will close it. If the new version of Barrier (2.3.4, when released) still has this bug, please reopen the issue. Thanks a lot!
@eiband commented on GitHub (Mar 18, 2021):
When will Barrier 2.3.4 be available?
@shymega commented on GitHub (Mar 18, 2021):
Unknown yet.
@Andy1978 commented on GitHub (Mar 30, 2021):
It is still a problem on a fresh build of cset
12024b9a5d@p12tic commented on GitHub (Jun 25, 2021):
@Andy1978 Could you please file a separate bug for that with logs and so on? It's likely that what you're seeing is a different issue, just that its symptoms are the same.