[GH-ISSUE #764] Macbook client always uses US keyboard layout #598

Open
opened 2026-05-05 06:44:56 -06:00 by gitea-mirror · 2 comments
Owner

Originally created by @simonporter007 on GitHub (Jun 23, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/764

Operating Systems

Server: Debian 10

Client: Macbook Pro Catalina 10.15.5

Barrier Version

Server: 2.2.0
Client: 2.3.2

Steps to reproduce bug

  1. Setup debian server using GB keyboard layout
  2. Connected MacBook client (input source also set to GB keyboard layout)
  3. Type with keyboard focused on Macbook client results in US layout
  4. Disconnect Barrier, typing on mac keyboard results in GB layout

Other info

I found similar issues though they all reference Linux as the client, and use a workaround to force the keyboard layout over CLI. I've tried this in case it worked, though I think the issue is Mac being the client in this case.

Originally created by @simonporter007 on GitHub (Jun 23, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/764 ### Operating Systems ### Server: Debian 10 Client: Macbook Pro Catalina 10.15.5 ### Barrier Version ### Server: 2.2.0 Client: 2.3.2 ### Steps to reproduce bug ### 1. Setup debian server using GB keyboard layout 2. Connected MacBook client (input source also set to GB keyboard layout) 3. Type with keyboard focused on Macbook client results in US layout 4. Disconnect Barrier, typing on mac keyboard results in GB layout ### Other info ### I found similar issues though they all reference Linux as the client, and use a workaround to force the keyboard layout over CLI. I've tried this in case it worked, though I think the issue is Mac being the client in this case.
Author
Owner

@github-actions[bot] commented on GitHub (Sep 19, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

<!-- gh-comment-id:695146220 --> @github-actions[bot] commented on GitHub (Sep 19, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.
Author
Owner

@p12tic commented on GitHub (Jan 10, 2021):

Let's not close valid bugs without a valid reason.

<!-- gh-comment-id:757532822 --> @p12tic commented on GitHub (Jan 10, 2021): Let's not close valid bugs without a valid reason.
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#598
No description provided.