mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #438] Right Alt doesn't work #341
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#341
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 @wjtk4444 on GitHub (Sep 18, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/438
Operating Systems
Server: Any (Linux?)
Client: Any (Windows?)
Barrier Version
Any
Steps to reproduce bug
Other info
I only use one language other than English, but I think that solving this issue could also close many others related to keyboard layouts and typing in non-latin characters.
For instance, to type
ą, I have to pressRALT+a. It does work on the host, but it doesn't on the client. When I toggle the right alt manually (via on-screen keyboard), it works as expected.I would suspect that Windows uses another keycode for RALT than Linux, and it simply ignores whatever is being sent.
key ef7e is not on keyboardis what I get from DEBUG1 on client.
@wjtk4444 commented on GitHub (Sep 20, 2019):
So, after (two?) years of using Barrier (and other syngery forks) almost everyday, I finally realized there's an option to configure it with a .conf file. Apparently, it allows one to remap keys at will. Well, better late than never.
Looking at some issue threads while also trying things out and failing (a lot), those are the two lines that fixed the issue. It looks like it makes no sense (if anything, I expected
altgr = altto work instead of this), but it just works.So, it seems that
f@!#ing manualreadme file earlierNot sure if there's a point in keeping this one open - not a Barrier specific bug and it's already reported and described well enough in synergy-core. I'm leaving the decision on whether to close or keep this one open to repository maintainers.
@p12tic commented on GitHub (Sep 21, 2019):
@AdrianKoshka Does it make sense to close the issue?
@AdrianKoshka commented on GitHub (Sep 21, 2019):
I suppose so, if this issue needs to be re-opened, it can be.
@Elexy commented on GitHub (Jul 23, 2020):
This saved me from insanity.
For reference: I use a wired mac keyboard on a Linux server and mixed Windows10 / linux clients
@wrzomar commented on GitHub (Dec 27, 2020):
For me it doesn't work. Only the
altgr = altmakes altgr "work" - the underscored characters appear in the window menu (like with left alt), but with alt the shortcuts work, with altgr not. Both client and server are using Linux. What am I missing?Edit: It works on Mac OS X client (meta=altgr, altgr=shift), but on Raspberry Pi OS client it doesn't for some reason.
@metebyte commented on GitHub (Apr 9, 2022):
Server (installed through release DMG):
macOS Monterey 12.3.1
Barrier Version: 2.4.0-release-3e0d758b
Client (installed through Pacman):
Arch Linux 5.17.1
Barrier Version: 2.4.0-release
Protocol version 1.6
Keyboard Layout on Server:
Turkish Q
Keyboard Layout on Client:
trq
Tried every method related to this issue. But couldn't get any good result.
@Eugeniusz-Gienek commented on GitHub (Jan 16, 2024):
Works for Mac - I have a couple of linuxes + mac and when writing Polish letters you use alt + a letter. Right alt didn't work so this is a revelation! Thanks!!!