[GH-ISSUE #434] Remapped compose key isn't accepted by client #336

New issue

Open

opened 2026-05-05 06:03:13 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 06:03:13 -06:00

Owner

Originally created by @xieve on GitHub (Sep 11, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/434

Operating Systems

Server: Microsoft Windows 7 Version 6.1 (Build: 7601 SP1)
Client: Arch Linux (Kernel: 5.2.9-arch1-1-ARCH)

Barrier Version

2.3.1

Steps to reproduce bug

Set right alt or any other key to be remapped as compose in Gnome Tweaks
Start barrier
Press right alt
Notice that the keystroke is ignored completely (even if I unset the mapping in Tweaks)

Workaround

Disable compose mapping, if existant
Start barrier
It works, no keystrokes ignored

Logs

Without workaround

[2019-09-11T22:37:20] DEBUG1: recv key down id=0x0000efea, mask=0x2004, button=0x0138
[2019-09-11T22:37:20] DEBUG1: mapKey efea (61418) with mask 2004, start state: 0000
[2019-09-11T22:37:20] DEBUG1: key efea is not on keyboard
[2019-09-11T22:37:20] DEBUG1: recv key up id=0x0000efea, mask=0x2000, button=0x0138

With workaround

[2019-09-11T22:40:34] DEBUG1: recv key down id=0x0000efea, mask=0x2004, button=0x0138
[2019-09-11T22:40:34] DEBUG1: mapKey efea (61418) with mask 2004, start state: 0000
[2019-09-11T22:40:34] DEBUG1: find best:  0000 2004
[2019-09-11T22:40:34] DEBUG1: best key index 1 of 1 (exact)
[2019-09-11T22:40:34] DEBUG1: found key in group 0
[2019-09-11T22:40:34] DEBUG1: state: 0000,0000,0001
[2019-09-11T22:40:34] DEBUG1: flip: 0000 (0000 vs 0000 in 0001 - 0000)
[2019-09-11T22:40:34] DEBUG1: desired state: 2004 0000,0000,0001
[2019-09-11T22:40:34] DEBUG1: flip: 0000 (0000 vs 2004 in fffa - 6020)
[2019-09-11T22:40:34] DEBUG1: mapped to 06c, new state 0004
[2019-09-11T22:40:34] DEBUG1: keystrokes:
[2019-09-11T22:40:34] DEBUG1:   06c (00000000) down
[2019-09-11T22:40:34] DEBUG1: recv key up id=0x0000efea, mask=0x2000, button=0x0138
[2019-09-11T22:40:34] DEBUG1: new state 0000
[2019-09-11T22:40:34] DEBUG1: keystrokes:
[2019-09-11T22:40:34] DEBUG1:   06c (00000000) up

Possible explanation

As it seems, the layout of the client's keyboard changes at software-side in a way that is intransparent or unaccounted for by barrier. As long as the original layout is present while starting barrier, that one is used as a reference, and the X server then interprets the keystroke in the right way. Maybe it would be helpful to have an option to configure some keystrokes manually?

Originally created by @xieve on GitHub (Sep 11, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/434 ### Operating Systems Server: Microsoft Windows 7 Version 6.1 (Build: 7601 SP1) Client: Arch Linux (Kernel: 5.2.9-arch1-1-ARCH) ### Barrier Version 2.3.1 ### Steps to reproduce bug 1. Set right alt or any other key to be remapped as compose in Gnome Tweaks 2. Start barrier 3. Press right alt 4. Notice that the keystroke is ignored completely (even if I unset the mapping in Tweaks) ### Workaround 1. Disable compose mapping, if existant 2. Start barrier 3. It works, no keystrokes ignored ### Logs #### Without workaround ``` [2019-09-11T22:37:20] DEBUG1: recv key down id=0x0000efea, mask=0x2004, button=0x0138 [2019-09-11T22:37:20] DEBUG1: mapKey efea (61418) with mask 2004, start state: 0000 [2019-09-11T22:37:20] DEBUG1: key efea is not on keyboard [2019-09-11T22:37:20] DEBUG1: recv key up id=0x0000efea, mask=0x2000, button=0x0138 ``` #### With workaround ``` [2019-09-11T22:40:34] DEBUG1: recv key down id=0x0000efea, mask=0x2004, button=0x0138 [2019-09-11T22:40:34] DEBUG1: mapKey efea (61418) with mask 2004, start state: 0000 [2019-09-11T22:40:34] DEBUG1: find best: 0000 2004 [2019-09-11T22:40:34] DEBUG1: best key index 1 of 1 (exact) [2019-09-11T22:40:34] DEBUG1: found key in group 0 [2019-09-11T22:40:34] DEBUG1: state: 0000,0000,0001 [2019-09-11T22:40:34] DEBUG1: flip: 0000 (0000 vs 0000 in 0001 - 0000) [2019-09-11T22:40:34] DEBUG1: desired state: 2004 0000,0000,0001 [2019-09-11T22:40:34] DEBUG1: flip: 0000 (0000 vs 2004 in fffa - 6020) [2019-09-11T22:40:34] DEBUG1: mapped to 06c, new state 0004 [2019-09-11T22:40:34] DEBUG1: keystrokes: [2019-09-11T22:40:34] DEBUG1: 06c (00000000) down [2019-09-11T22:40:34] DEBUG1: recv key up id=0x0000efea, mask=0x2000, button=0x0138 [2019-09-11T22:40:34] DEBUG1: new state 0000 [2019-09-11T22:40:34] DEBUG1: keystrokes: [2019-09-11T22:40:34] DEBUG1: 06c (00000000) up ``` ### Possible explanation As it seems, the layout of the client's keyboard changes at software-side in a way that is intransparent or unaccounted for by barrier. As long as the original layout is present while starting barrier, that one is used as a reference, and the X server then interprets the keystroke in the right way. Maybe it would be helpful to have an option to configure some keystrokes manually?

gitea-mirror commented

2026-05-05 06:03:17 -06:00

Author

Owner

@arkag commented on GitHub (Oct 20, 2021):

Unsure if this is the same, but I'm actually trying to use WinCompose in a Windows 10 Server/Windows 10 Client situation.

Looks like alt (both right and left) are completely ignored by Barrier and aren't passed to the client barrier computer, meaning leveraging WinCompose with Barrier isn't possible. Is there a way to force Barrier to pass alt to the client?

Also, I'm aware I'm necro-ing the hell out of this, but I'm unsure where else to go for help.

@arkag commented on GitHub (Oct 20, 2021): Unsure if this is the same, but I'm actually trying to use WinCompose in a Windows 10 Server/Windows 10 Client situation. Looks like alt (both right and left) are completely ignored by Barrier and aren't passed to the client barrier computer, meaning leveraging WinCompose with Barrier isn't possible. Is there a way to force Barrier to pass alt to the client? Also, I'm aware I'm necro-ing the hell out of this, but I'm unsure where else to go for help.