[GH-ISSUE #438] Right Alt doesn't work #341

Closed
opened 2026-05-05 06:04:17 -06:00 by gitea-mirror · 7 comments
Owner

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

  1. Open on-screen keyboard on Windows client - it highlights currently pressed modifier keys
  2. Press LSHIFT, LCTRL, LALT, RALT, RCTRL, RSHIFT
  3. Noitice that only RALT doesn't light up when pressed

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.

Polish is written with the standardized Polish alphabet, which has nine additions to the letters of the basic Latin script (ą, ć, ę, ł, ń, ó, ś, ź, ż).

For instance, to type ą, I have to press RALT+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 keyboard
is what I get from DEBUG1 on client.

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 ### 1. Open on-screen keyboard on Windows client - it highlights currently pressed modifier keys 2. Press LSHIFT, LCTRL, LALT, RALT, RCTRL, RSHIFT 3. Noitice that only RALT doesn't light up when pressed ### 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. > Polish is written with the standardized Polish alphabet, which has nine additions to the letters of the basic Latin script (ą, ć, ę, ł, ń, ó, ś, ź, ż). For instance, to type `ą`, I have to press `RALT+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 keyboard` is what I get from DEBUG1 on client.
gitea-mirror 2026-05-05 06:04:17 -06:00
Author
Owner

@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 = alt to work instead of this), but it just works.

section: screens
    linux:
    windows7:
        meta = altgr
        altgr = shift
end

So, it seems that

  • the issue can be worked around
  • I'm an idiot for not reading the f@!#ing manual readme file earlier

Not 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.

<!-- gh-comment-id:533463888 --> @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](https://github.com/symless/synergy-core/wiki/Text-Config). Apparently, it allows one to remap keys at will. Well, better late than never. Looking at some [issue threads](https://github.com/symless/synergy-core/issues/4411) 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 = alt` to work instead of this), but it just works. ``` section: screens linux: windows7: meta = altgr altgr = shift end ``` So, it seems that * the issue can be worked around * I'm an idiot for not reading the ~~f@!#ing manual~~ readme file earlier Not 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](https://github.com/symless/synergy-core). I'm leaving the decision on whether to close or keep this one open to repository maintainers.
Author
Owner

@p12tic commented on GitHub (Sep 21, 2019):

@AdrianKoshka Does it make sense to close the issue?

<!-- gh-comment-id:533799803 --> @p12tic commented on GitHub (Sep 21, 2019): @AdrianKoshka Does it make sense to close the issue?
Author
Owner

@AdrianKoshka commented on GitHub (Sep 21, 2019):

I suppose so, if this issue needs to be re-opened, it can be.

<!-- gh-comment-id:533817931 --> @AdrianKoshka commented on GitHub (Sep 21, 2019): I suppose so, if this issue needs to be re-opened, it can be.
Author
Owner

@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

<!-- gh-comment-id:662849319 --> @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
Author
Owner

@wrzomar commented on GitHub (Dec 27, 2020):

For me it doesn't work. Only the altgr = alt makes 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.

<!-- gh-comment-id:751410795 --> @wrzomar commented on GitHub (Dec 27, 2020): For me it doesn't work. Only the `altgr = alt` makes 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.
Author
Owner

@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.

<!-- gh-comment-id:1093614580 --> @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.
Author
Owner

@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!!!

<!-- gh-comment-id:1893976007 --> @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!!!
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#341
No description provided.