[GH-ISSUE #1114] Cursor locking doesn't work when using secondary keyboard layout, a key event is sent instead #893

New issue

Open

opened 2026-05-05 07:15:07 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 07:15:07 -06:00

Owner

Originally created by @epakai on GitHub (Apr 2, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1114

Describe the bug
Pressing Scroll lock (for lock cursor to screen) while using my secondary keyboard layout sends a keypress instead of activating the cursor lock.

My server is Linux, with a Windows client. Host keyboard layouts are US,Dvorak and US,Basic (no variant). I don't think the particular layout has anything to do with this bug though. It feels more like some state is being set that affects a check in barrier. For example I also saw this same issue mentioned in this comment when using a Czech layout:
https://github.com/debauchee/barrier/issues/1005#issuecomment-761838291

To Reproduce
Steps to reproduce the behavior:

Have a second keyboard layout on a Linux barrier server, and some way to toggle layouts. I used: 'setxkbmap -option grp:menu_toggle -layout us,us -variant dvorak,basic'
Run barrier with a windows client and ScrollLock as lockCursorToScreen(toggle).
Example config:

section: screens
server:
client:
end

section: links
server:
    right(5,95) = client(5,95)
client:
    left(5,95) = server(5,95)
end

section: options
    heartbeat = 5000
    relativeMouseMoves = true
    keystroke(ScrollLock) = lockCursorToScreen(toggle)
end

Switch keyboard layout (press menu key in my case). This can also be done after step 4.
Move mouse cursor to client machine.
Press Scroll Lock.
Cursor isn't locked to the screen.

Expected behavior
Cursor lock should be enabled after pressing scroll lock.

Desktop (please complete the following information):
Server:

OS: Debian 10.9
Barrier version: 2.2.0-Release
Client:
OS: Windows 10 (20H2)
Barrier version: 2.1.0-Release

Additional context
Workaround: It's possible to switch to the primary keyboard layout, apply the cursor lock, then toggle keyboard layouts again to work on a client with cursor locked and the second layout.

The key id sent from the server log looks like:

DEBUG1: event: KeyPress code=78, state=0x2000
DEBUG1: onKeyDown id=61204 mask=0x0000 button=0x004e

The key id received on the client log looks like:

DEBUG1: recv key down id=0x0000ef14, mask=0x0000, button=0x004e
DEBUG1: ignored key ef14 0000
DEBUG1: recv key up id=0x0000ef14, mask=0x0000, button=0x004e

Additional mentions of this keycode and bug were in these issue comments. One from synergy, and one from barrier:
https://github.com/symless/synergy-core/issues/6059#issuecomment-313870115
https://github.com/debauchee/barrier/issues/1005#issuecomment-761838291

Originally created by @epakai on GitHub (Apr 2, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1114 **Describe the bug** Pressing Scroll lock (for lock cursor to screen) while using my secondary keyboard layout sends a keypress instead of activating the cursor lock. My server is Linux, with a Windows client. Host keyboard layouts are US,Dvorak and US,Basic (no variant). I don't think the particular layout has anything to do with this bug though. It feels more like some state is being set that affects a check in barrier. For example I also saw this same issue mentioned in this comment when using a Czech layout: https://github.com/debauchee/barrier/issues/1005#issuecomment-761838291 **To Reproduce** Steps to reproduce the behavior: 1. Have a second keyboard layout on a Linux barrier server, and some way to toggle layouts. I used: 'setxkbmap -option grp:menu_toggle -layout us,us -variant dvorak,basic' 2. Run barrier with a windows client and ScrollLock as lockCursorToScreen(toggle). Example config: ``` section: screens server: client: end section: links server: right(5,95) = client(5,95) client: left(5,95) = server(5,95) end section: options heartbeat = 5000 relativeMouseMoves = true keystroke(ScrollLock) = lockCursorToScreen(toggle) end ``` 3. Switch keyboard layout (press menu key in my case). This can also be done after step 4. 4. Move mouse cursor to client machine. 5. Press Scroll Lock. 6. Cursor isn't locked to the screen. **Expected behavior** Cursor lock should be enabled after pressing scroll lock. **Desktop (please complete the following information):** Server: - OS: Debian 10.9 - Barrier version: 2.2.0-Release Client: - OS: Windows 10 (20H2) - Barrier version: 2.1.0-Release **Additional context** Workaround: It's possible to switch to the primary keyboard layout, apply the cursor lock, then toggle keyboard layouts again to work on a client with cursor locked and the second layout. The key id sent from the server log looks like: > DEBUG1: event: KeyPress code=78, state=0x2000 > DEBUG1: onKeyDown id=61204 mask=0x0000 button=0x004e The key id received on the client log looks like: > DEBUG1: recv key down id=0x0000ef14, mask=0x0000, button=0x004e > DEBUG1: ignored key ef14 0000 > DEBUG1: recv key up id=0x0000ef14, mask=0x0000, button=0x004e Additional mentions of this keycode and bug were in these issue comments. One from synergy, and one from barrier: https://github.com/symless/synergy-core/issues/6059#issuecomment-313870115 https://github.com/debauchee/barrier/issues/1005#issuecomment-761838291