mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #100] Cannot type characters that need Alt Gr key #74
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#74
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 @blizarazu on GitHub (Jul 22, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/100
Operating Systems
Server: Ubuntu 18.04 (kernel 4.15.0-29-generic)
Client: Windows 10 Home version 1830 (OS compilation 17134.167)
Barrier Version
2.1.0
Steps to reproduce bug
Alt Gr key does not work and characters such as @ { } [ ] # can't be used in the client. For example:
1- Try to write an @ with a Spanish keyboard in the client. You have to press Alt Gr+2.
2- Windows keyboard layout changes to english when you press Alt Gr+2 and a 2 is written instead of @. If Windows is configured only with Spanish keyboard, the language does not change but nothing appears when you press Alt GR + another key.
I also notices that the language switches back to Spanish if you press Shift+3 (this also types a ·).
Other info
@maxbla commented on GitHub (Jul 28, 2018):
Synnergy's old github wiki makes me think your issue was never planned for, as there is no alt gr key listed in their text config guide
@DuschdrBabbe commented on GitHub (Aug 16, 2018):
Have the same problem here! Windows7 (Server) Raspi Rasbian (Client)
please fix it :-)
for backslash i use now ALT 92
@BelgarathS commented on GitHub (Sep 3, 2018):
Hi,
I have the same problem
how would we implement that, it is critical issue for anybody using non-us keyboard.
Best regards
Paul
@BelgarathS commented on GitHub (Sep 4, 2018):
Hi,
I have identified that altgr is passed as ctrl+alt (this is altgr equivalent for windows but not linux) and that is where the problem begins.
Moreover adding either
shit=altgr
or
alt=altgr
in screen sections (in client config) allow to use those modifier keys to work as proper altgr so it seems more a problem on windows serve side and capturing the original altgr signal rather than alt+control as altgr=anymeta does not work in either client nor server section
moreover alt+ctrl is quite widely used on linux nowadays (f.e workspace manipulation) so even intercepting ctrl+alt and changing it back to altgr seems not to be a proper solution.
@BelgarathS commented on GitHub (Sep 4, 2018):
as a temporary workaround in ubuntu using gnome-tweaks using
keyboard&mouse/additional layout option/key to choose 3rd level/menu key
allows me to use menu key from windows keyboard as altgr on linux client
@lucas-gaitzsch commented on GitHub (Sep 6, 2018):
I have the same Problem with Linux Server, Windows Client and german keyboard.
@BelgarathS commented on GitHub (Sep 6, 2018):
With windows client you can just add alt=altgr or altgr=alt in your server config in your windowspc: section and that should work
@BelgarathS commented on GitHub (Sep 11, 2018):
On further investigation, choice of window keymap has tremendous impact on how the keys are being transmitted. I believe we are not capturing the data early enough in the process and the keymap translations are done before we get scan-codes on windows.
@digitizer0 commented on GitHub (Sep 30, 2018):
Have the same issue Linux server, Windows Client
@maxbla commented on GitHub (Oct 9, 2018):
To whoever tries to squash this bug, this looks suspicious:
From lines 115-123 of KeySequence.cpp
and I found some documentation (find on page Key_AltGr)
@niikoo commented on GitHub (Dec 1, 2018):
This fixes the problem on version 2.2.0-Release-00000000 (October 10, 2018)
Working with Linux (Ubuntu 18.10 with kernel 4.19.5) and Windows 10.
Source
@gerardparareda commented on GitHub (Dec 30, 2018):
I am having a similar problem but not only with the altgr key, all the symbols are wrong. I've got the same keyboard (client and server) but for example a Shift + 0 is '=' in the server and '_' in the client. These are a qwerty spanish with the middle dot keyboard. Client is running Ubuntu 18.04 LTS and the server Windows 10. Any idea?
@AdrianKoshka commented on GitHub (Dec 30, 2018):
Perhaps open a new issue @Raxe88?
@gerardparareda commented on GitHub (Jan 1, 2019):
Sorry about that. For anyone interested I found the solution to my problem on this issue.
@kakra commented on GitHub (May 3, 2019):
This is still a problem with 2.2.0, using a Linux server with a Windows 10 client, and using German keyboard layout. Characters like
@,\, or~are on the third key level and need AltGr (right Alt-key) to be entered.My work-around is currently using left Alt+Ctrl (which emulates AltGr in most OSes) to enter these characters but this is very uncomfortable as a German keyboard user.
@digitizer0 commented on GitHub (May 8, 2019):
I solved this in config file by setting the following:
section: screens
windowsmachine1:
meta = altgr
altgr = shift
windowsmachine2:
meta = altgr
altgr = shift
end
@marsie321 commented on GitHub (May 28, 2019):
This a very old bug. To conclude:
AltGr e.g. for @ at german keyboard is working with Linux-Server and Windows Client partial working:
a) altgr=shift # OK, standalone at win10, but not at WSL bash@win10
b) but not with putty, wsl (Windows Subsystem for Linux) e.g. bash, see attached xev output
c) WORKAROUND: synergy-v1.8.2-stable-36cd521-Windows-x64.msi + # altgr=alt # OK, (win10 + wsl/putty) ... but only synergy <= 1.8.2.
WRONG (from linux server)
KeyRelease event, serial 33, synthetic NO, window 0x380001,
root 0x5a5, subw 0x0, time 3031843, (80,95), root:(398,436),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
OK (windows clients keyboard)
KeyRelease event, serial 33, synthetic NO, window 0x380001,
root 0x5a5, subw 0x0, time 3110031, (1237,773), root:(1581,1140),
state 0x80, keycode 20 (keysym 0x5c, backslash), same_screen YES,
XLookupString gives 1 bytes: (5c) ""
XFilterEvent returns: False
@felix-ht commented on GitHub (Aug 12, 2019):
This fixed it for me as well on 2.3.1 Linux server and 2.3.1 Windows Client. Any plans to actually fix this properly?
@spaeps commented on GitHub (Sep 5, 2019):
I just want let you know that the Alt-Gr key and everyone else works perfectly after client suspension and resume.
I'm just dealing with Linux, since I do not use barrier with anything else.
My setup:
Both Server and Client: Arch Linux with barrier 2.3.1 and Italian layout
For reference, the Italian keyboard layout.
Steps:
Probably something in the resume process triggers the fix but i need to investigate.
I'll let you know.
@BelgarathS commented on GitHub (Sep 5, 2019):
This is specific windows issue when windows keymap seems to be applied before the keys are intercepted by barrier.Specifically changing keyboard language affects keys that barrier sends across.
@JohanMollevik commented on GitHub (Sep 10, 2019):
I am also affected, I have a linux server and windows client. When I type AltGr+7 to type a '{' symbol a '[' symbol shows up and the windows client changes keyboard layout from SV to EN. Similar things happens for other symbols.
@nlubisch commented on GitHub (Sep 10, 2019):
Same problem.
Server: Ubuntu 18.04
Client Windows 10
@DrillSergeant commented on GitHub (Nov 15, 2019):
Also same problem.
Server: Ubuntu 18.04
Client Windows 10 Pro
@barnaba commented on GitHub (Jan 9, 2020):
Same problem. ubuntu server 2.3.2 snapshot
9080ce45, client win 10 2.3.2 snapshot210c2b70)I've incorporated @niikoo's solution and it seemed to work for most cases. Used it for some time, but finally ran into issues.
While alt+o produces the proper "ó" character in most settings (e.g. notepad) it fails in other. For example in ms word.
What happens when I use alt gr + o on client's physical keyboard: "ó" character
What happens when I use right alt + o on server and it goes through barrier: ms word opens the outlining ribbon
This is quite breaking from my perspective, litearlly can't type in polish with any reasonable speed.
Here's my config:
@MPalix86 commented on GitHub (Jan 17, 2020):
Also same problem.
Server: macOS Catalina 10.15.2 (mackbook keyboard)
Client: Kali linux 2019.4 (classic windows pc keyboard)
In addition on mac the alt gr key is not present.
@jemielniak commented on GitHub (Feb 6, 2020):
Same issue - makes the system not sustainable for users of languages with non-standard characters (mine is Polish).
@wscheicher commented on GitHub (Feb 7, 2020):
I just observed something strange:
While last week i realized that AltGr wouldn't work (Windows 10 as Server, Debian Buster as Client) and i stumbled over this bug and actually didn't see how this could be solved - strangely the problem vanished without me changing anything.
What i did however: i installed WSL and XcXsrv ... i wonder if that did change something on the Server side ...
@jemielniak commented on GitHub (Feb 7, 2020):
Thanks! I tried that (I installed WSL and then XcXsrv) and unfortunately it didn't work for me.
@wscheicher commented on GitHub (Feb 12, 2020):
Update: Looks like it had nothing to do with what i installed on Windows, but rather with my keyboard settings on the linux client. It seems that after having barrierc running, the keyboard layout was not matching the local keyboard, but had a "us" layout - or so. And after several attempts to fix that, and a reboot - some key combinations did work. Not "real" AltGr, but at least @€{}...
I did:
xinput list
setxkbmap -device 5 at # 5 being the ID of my "Virtual core XTEST keyboard"
and then rebooted both PCs
Also messed with dpkg-reconfigure keyboard-configuration and kde keyboard settings, so not 100% sure what actually triggered the change in the behaviour.
@allbombson commented on GitHub (Feb 25, 2020):
I have a similar issue when using a Japanese keyboard, and multiply keys are passed at times and most the time none are correct.
@allbombson commented on GitHub (Feb 25, 2020):
I have a similar issue when using a Japanese keyboard, and multiply keys are passed at times and most the time none are correct.
@allbombson commented on GitHub (Feb 25, 2020):
I have a similar issue when using a Japanese keyboard, and multiply keys are passed at times and most the time none are correct.
@thothothotho commented on GitHub (May 5, 2020):
I have a similar problem with the french bépo layout (https://bepo.fr/wiki/Accueil)
It relies heavily on AltGr, even for pure ascii characters (like {}<>)
setup:
Ubuntu18 (server)
Windows10 (client)
Here is the keys I hit :
AltGr-X(Here by
X, I mean the physical key that is placed at the posiition of the letterXon a us keyboard)According to the bépo layout, this should generate a
{But I observe a
[being generated instead (and the keyboard indicator on windows 10 switch to EN)Here are some more examples:
{[}]<,>.[[]]&7|\Here is a theory that (partially) explains those results.
The server (ubuntu) sends the KeyCode to the client (windows 10). The client looks up where is that keycode on a US keyboard, then it removes the shift modifier and consider this is the result.
At least there is a strong correlation between Expected and Results. They are always on the same physical key on a us keyboard.
@sgrienen commented on GitHub (May 8, 2020):
I have the same kind of problems, I'm using an Apple keyboard on my MacOS and to control a Win10 PC and Alt-Gr is not working (right Alt key + G should output a @ symbol but I can't get it on Win10 unless I use the left Ctrl+Alt as described by someone in that thread... it's a pain, I wish I could configure it, but I've tried to add
meta = altgr
altgr = shift
in the config file, it doesn't change anything for me.
@aapopajunen commented on GitHub (Jun 4, 2020):
Having same issues with finnish keyboard layout.
Client: Windows 10
Server: Pop!_OS 20.04 LTS x86_64
@hevi9 commented on GitHub (Jun 8, 2020):
Same issue, finnish keyboard
server: Kubuntu 19.10
client: Windows 10 Pro
@lgallard commented on GitHub (Jun 18, 2020):
As @digitizer0 pointed out, to workaround this add the following to your screens config:
Here you are Screens configuration in Barrier's config file:
@1ras commented on GitHub (Jul 20, 2020):
meta = altgrdoes nothing at all andaltgr = shiftis only a partly workaround as some AltGr combinations are still not working, like ~ (AltGr +) and € (AltGr e) on a Germany keyboard.Also when looking on the actual keys received on the Windows client with this workaround, the key sequence is still wrong. E.g. AltGr + is received as:
Where a locally pressed Altgr + just correctly shows as:
Traces are done with the Autohotkey KeyHistory command, with the following meaning:
VK=Virtual Key, SC=Scan Code, Elapsed=Seconds since the previous event. Types: h=Hook Hotkey, s=Suppressed (blocked), i=Ignored because it was generated by an AHK script, a=Artificial, #=Disabled via #IfWinActive/Exist, U=Unicode character (SendInput).
Server: Debian 10 with Barrier 2.3.2
Client: Windows 10 with Barrier 2.3.2
@ghost commented on GitHub (Oct 15, 2020):
Server: Windows 10 with Barrier 2.3.3
Client: macOS 10.15 with Barrier 2.3.3
Can't use AltGr because it sends Ctrl+Alt, and in my case (Polish keyboard layout) it does not allow for diacritic characters to be typed. Breaking bug for me, because Right Alt + L is one of the important letters that are often used. Swapping to the nearest key (Meta/Windows) causes Windows 10 to log off (Win + L).
@domalex commented on GitHub (Jan 1, 2021):
I have been experiencing the same problem with a Swiss German keyboard. The Barrier server works flawlessly from an Arch Linux installation. However, on when using the Barrier client on a Windows 10 machine it would not recognize most keystrokes executed in combination with the AltGr key, such as @ | ¼ ½ ¢ ¬ etc.
A fix would be very much appreciated as this is a critical issue for users who depend on a working AltGr key.
@Cramsarg commented on GitHub (Jan 5, 2021):
In PuTTY configuration, "Terminal/Keyboard" topics, by default option "Control-Alt is different from AltGr" is checked.
Unchecking this option give me back @ | { [ ] } € characters in PuTTY.
There's also a second option "AltGr act as Compose key" I let unchecked.
barrier server : 2.3.2 (Ubuntu 20.10)
barrier client : 2.3.3 (Windows 7)
KiTTY 0.73.0.1 (PuTTY fork, same options for AltGr as PuTTY )
French keyboard layout.
Hope this may help some of you.
@AdrienGuimbal commented on GitHub (Jan 16, 2021):
I see a lot of comment about adding
in my config file, but how can I do it on Windows 10?
In Linux we can use
synergy-core --config <filename>but the command isn't available on windows?@GilDev commented on GitHub (Feb 3, 2021):
Same issue on macOS 11.1 server and Windows 10 2004 client on Barrier 2.3.3 using the Bépo keyboard layout. No “altgr” setting anywhere in the GUI configurator.
Breaking bug that makes me unable to use this software in my case.
@lululock71 commented on GitHub (Feb 7, 2021):
I've got the same issue too... But I kinda solved it by using LCtrl + LAlt instead of AltGr. I know that AltGr is interpreted as LCtrl + LAlt by Windows, but what's weird is that Linux does not react at all when doing this key combo... I guess I'll have to get used to that, it's better than not being able to access those characters.
I don't know what causes this oddity, but note that I've explicitly set the AZERTY keyboard variant for Xorg, which allows me to type characters normally unaccessible with other OSes, such as "É" (CapsLock + 2 (é)) or even "Ù" (CapsLock + ù).
French (AZERTY) layout
Server : Arch Linux (xanmod-rt) with Barrier 2.3.3
Client : Windows 10 20H2 with Barrier 2.3.3
@xiduis15 commented on GitHub (Mar 4, 2021):
Same issue
macOS 11.1 server
windows and ubuntu clients.
no altgr available; impossible to do the characters @ and # on a keyboard fr
@matrixes commented on GitHub (Mar 29, 2021):
I have issues with AltGr as everyone else in this issue.
I'm running
Using the workaround
make most things in Windows accept
AltGr+?=\andAltGr+2=@.However,
AltGr+8([) followed byAltGr+2to get the@character.@char appear at all, no matter what combination I use``(backticks/grave accent) and´(acute accent) characters do not work at all, which incidentally makes it difficult to type code blocks here without cutting and pasting. :)@SoftwareSchlosser commented on GitHub (Apr 27, 2021):
Same for me, can't type characters like {} via AltGr on a german keyboard on a Windows 10 guest connected to a Linux (Ubuntu) host. The workarounds mentioned here didn't work for me.
@kakra commented on GitHub (Apr 27, 2021):
I have given up on this problem, I'm not even sure if it can be worked around in Windows because many Windows remote control products have similar issues with the AltGr key (even with Windows-to-Windows remoting) or certain keys/characters are not passed down to some types of windows (MSTSC, WSL) - seems to be a problem intrinsic to the Windows input system.
@SoftwareSchlosser commented on GitHub (Apr 27, 2021):
Maybe one way would be to emulate the AltGr key by sending Ctrl+Alt instead - at least I can type a
{by pressingCtrl+Alr+8. At least it would be nice to have this as an option in Barrier.I already tried to simply do this by using a HotKey but obviously AltGr can't be used as a HotKey either.
@arnholm commented on GitHub (May 24, 2021):
Kubuntu 20.04 as Barrier server
Windows 10 as Barrier client
Norwegian keyboard
I was hit by this problem as well. This problem made Barrier unusable, since none of @£${[]} could be sent from Server to Client.
The work-around described above that seems to work for me is
1 On the server, save the barrier.conf file
2 On the server, edit barrier.conf and add for the Windows 10 client screen
meta = altgr
altgr = shift
3. On the server, reload barrier.conf
4. Verify that @£${[]} works on the client
Thanks for maintaining Barrier! Maye this issue can be fixed more permanently, so Barrier is easier to use with non-english keyboards.
@GilDev commented on GitHub (May 25, 2021):
Those fixes didn’t work for me on macOS with Windows, and it makes Barrier completely unusable for my usage (can’t do _'€& and so on as I type with the Bépo layout).
I can’t really complain because Barrier is free and community-based, but right now I have no software that can help me.
@xuijuthub commented on GitHub (Jul 9, 2021):
Try NoMachine for the time being, although it is remote desktop software => will show video.
Although this bug fixed, now that would be awesome.
@amigainc commented on GitHub (Aug 6, 2021):
Hello, I have this problem too on a Windows client, Alt-GR working on Linux server:
I haven't this issue when the server is a Windows computer.
@steelman commented on GitHub (Sep 7, 2021):
I've described a similar case in #1280. I am not sure if directly related to AltGr.
@jmymay commented on GitHub (Nov 23, 2021):
altgr = shiftdoesn't work for me with macOS server and Linux client. It seems Linux handles the Barrier's Alt_L in some way which precludes it from interpreting it as a modifier key. I've made a hack for my use case (Polish characters) at https://github.com/jkozera/barrier/tree/fix-pl-chars which injects modified keycodes, using a hardcoded map of letters to corresponding diacritics, and removes Alt from modifiers. I still couldn't type anything with Alt pressed, so I've also implemented triggering of fake Alt "key up" event and only now it works. The magic constant button=59 also seems important, because without it I couldn't type uppercase characters.@Infor-Master commented on GitHub (Nov 27, 2021):
same problem, currently using mac server with linux client using an "apple magic keyboard" with a portuguese layout. The linux perceives both alt keys as Alt_L instead of assuming the right one as Alt Gr (or iso_level3_shift) wich prevents me from typing some symbols like @ on the keyboard.
@JDuchniewicz commented on GitHub (Dec 8, 2021):
This fix:
Worked for me with Arch Linux as server and W10 as client. One caveat: you cannot name your config file
.barrier.confand place it in your home directory otherwise barrier complains about wrong structure of the file. Therefore, I had to place it in~/.config/barrrier.conf#1473.@JMLX42 commented on GitHub (Dec 18, 2021):
Windows 10 server + Ubuntu 21.10 client, the following is working for me:
@mko-callpage commented on GitHub (Aug 23, 2022):
why hasn't this been fixed for so many years?! T_T
@p145085 commented on GitHub (Oct 24, 2022):
This fixes my issue.
Windows 10 as Synergy server. Raspberry Pi running Raspbian as Synergy client.
Added
altgr = metaundersection: screens.@erikderzweite commented on GitHub (Jan 26, 2023):
meta = altgr and altgr = shift fixes the issue for most Windows programs, but not for the WLS where I need it the most.
I have an ubuntu as a server and Windows 11 as a client. Anyone had the same issue?
@pacc commented on GitHub (Mar 14, 2023):
Using Debian server and Windows 11 + WSL, swedish keyboard layout
meta = altgr and altgr = shift in the client section works for me now
In WSL terminals there were a bunch of ctrl + alt +'num' shortcuts that has to be deleted or changed
or they will override {[]} key presses.
@federstedt commented on GitHub (Apr 30, 2023):
Thanks, this solved my issues aswell!
@ohbibi-glacava commented on GitHub (Sep 25, 2023):
Same for me, on Arch server to Windows client setup, just have to add
altgr = shifton client section, to the server configuration file and it works perfectly.Nothing to do on client configuration file, just one line on server configuration file.
Thank's
@mattia-donato commented on GitHub (Jun 13, 2024):
I would add just an info. I use barrier (server-Linux and client-Linux) I do not have problem. But I see the bug only in the Virtual Machine running Windows on it even if the system running it is fine. In other words: in a client system when I use
altGr+ò(ITA keyboard) in Gnome gives properly@, instead just moving inside the window running Windows in a VMaltGr+ògivesq.@CasperBonde commented on GitHub (Oct 1, 2024):
the altgr = shift addition worked for me, but took a while to figure out how barrier uses the config files - hence it did not work initially. Also it only works in some applications like notepad++ and Eclipse. It does not work in Micrsoft programs like OneNote, but does work in other Microsoft programs like Outlook?
To use it you need to export you config by selecting "Save Configuration" - then open the file saved and add
altgr = shiftfor each of the clients where you want this mapping - for example if you have multiple windows PC's.
Then in Barrier change the main UI to "Use Existing Configuration" and point to the file you modified.
