github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #603] Keyboard layout issue #472

New issue

Open

opened 2026-05-05 06:29:48 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 06:29:48 -06:00

Owner

Originally created by @vitek on GitHub (Mar 29, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/603

Operating Systems

Server: Ubuntu 16.04.6 LTS

Client: Ubuntu 16.04.6 LTS

Barrier Version

barriers 2.3.2-snapshot (11edf04107)

Steps to reproduce bug

I'm experiencing two different locale related bugs in different WM.

Awesome wm host

Awesome wm server, keyboard layout setup:

setxkbmap -layout us,ru

Awesome switches keyboard using xcb bindings.

When I switch to the barrier client screen it all works as expected (I can type and I can switch layout on client) if I was in english layout on the server side.

But if I switch to the client with russian layout selected on the server I can only input russian text on the client side and layout switch doesn't work (or I can't type at all).

I think I've nailed this down when russian layout is chosen there is extra 0x2000 state flag set. I didn't find its meaning perhaps it's part of layout group index.

So when I press 'F' on the server with english I got this:

[2020-03-29T08:09:45] DEBUG1: event: KeyPress code=41, state=0x0000
[2020-03-29T08:09:45] DEBUG1: onKeyDown id=102 mask=0x0000 button=0x0029
[2020-03-29T08:09:45] DEBUG1: send key down to "vitja-yatop" id=102, mask=0x0000, button=0x0029
[2020-03-29T08:09:45] DEBUG1: new mask: 0x0000
[2020-03-29T08:09:45] DEBUG1: event: KeyRelease code=41, state=0x0000
[2020-03-29T08:09:45] DEBUG1: onKeyUp id=102 mask=0x0000 button=0x0029
[2020-03-29T08:09:45] DEBUG1: send key up to "vitja-yatop" id=102, mask=0x0000, button=0x0029
[2020-03-29T08:09:46] DEBUG1: new mask: 0x0000

With russian locale (and input does not work on the client side):

[2020-03-29T08:10:02] DEBUG1: event: KeyPress code=41, state=0x2000
[2020-03-29T08:10:02] DEBUG1: onKeyDown id=1072 mask=0x0000 button=0x0029
[2020-03-29T08:10:02] DEBUG1: send key down to "vitja-yatop" id=1072, mask=0x0000, button=0x0029
[2020-03-29T08:10:02] DEBUG1: new mask: 0x0000
[2020-03-29T08:10:02] DEBUG1: event: KeyRelease code=41, state=0x2000
[2020-03-29T08:10:02] DEBUG1: onKeyUp id=1072 mask=0x0000 button=0x0029
[2020-03-29T08:10:02] DEBUG1: send key up to "vitja-yatop" id=1072, mask=0x0000, button=0x0029
[2020-03-29T08:10:04] DEBUG1: new mask: 0x0000

Client message:

[2020-03-29T08:15:06] DEBUG1: recv key down id=0x00000430, mask=0x0000, button=0x0029
[2020-03-29T08:15:06] DEBUG1: mapKey 0430 (1072) with mask 0000, start state: 0000
[2020-03-29T08:15:06] DEBUG1: key 0430 is not on keyboard
[2020-03-29T08:15:06] DEBUG1: recv key up id=0x00000430, mask=0x0000, button=0x0029
[2020-03-29T08:15:07] DEBUG1: recv key down id=0x00000430, mask=0x0000, button=0x0029
[2020-03-29T08:15:07] DEBUG1: mapKey 0430 (1072) with mask 0000, start state: 0000
[2020-03-29T08:15:07] DEBUG1: key 0430 is not on keyboard
[2020-03-29T08:15:07] DEBUG1: recv key up id=0x00000430, mask=0x0000, button=0x0029
[2020-03-29T08:15:07] DEBUG1: recv key down id=0x00000430, mask=0x0000, button=0x0029
[2020-03-29T08:15:07] DEBUG1: mapKey 0430 (1072) with mask 0000, start state: 0000
[2020-03-29T08:15:07] DEBUG1: key 0430 is not on keyboard
[2020-03-29T08:15:07] DEBUG1: recv key up id=0x00000430, mask=0x0000, button=0x0029

Dirty hack with ignoring 0x2000 state flag helped me, see
cf4fc3334a

Ubuntu's 16.04 Unity host

In general problem is the same, barrier is sending current layout keysym. But in this case unity does not use 0x2000 state flag. Keysym mapping occurs inside xcb internals.

Here is simple program:

#include <X11/Xlib.h>
#include <stdio.h>

int main()
{
    Display *dpy = XOpenDisplay(NULL);
    if (!dpy) {
        perror("XOpenDisplay()");
        return 1;
    }

    KeySym sym = XkbKeycodeToKeysym(dpy, 42, 0, 0);
    printf("%d\n", sym);

    return 0;
}

In case of unity16.04 result depends on the current layout chosen. In Awesome and in ubuntu 18.04 it doesn't (according to xev they both use 0x2000 flag). So perhaps it's problem of unity16.04.

Other info

Who is responsible for layout switch client or server? Should barrier server send keycodes to the client with respect to the current server's layout?

Currently I'm happy with my patch it forces barrier to send english keysyms and X11 on the client side translates it to the client's layout.

Anyway I would like to see a clean solution to this problem that would be applied to upstream version.

Originally created by @vitek on GitHub (Mar 29, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/603 ### Operating Systems ### Server: Ubuntu 16.04.6 LTS Client: Ubuntu 16.04.6 LTS ### Barrier Version ### barriers 2.3.2-snapshot (11edf04107bec4ea7159c4dab6949adfe4be9bee) ### Steps to reproduce bug ### I'm experiencing two different locale related bugs in different WM. #### Awesome wm host #### Awesome wm server, keyboard layout setup: `setxkbmap -layout us,ru` Awesome switches keyboard using xcb bindings. When I switch to the barrier client screen it all works as expected (I can type and I can switch layout on client) if I was in english layout on the server side. But if I switch to the client with russian layout selected on the server I can only input russian text on the client side and layout switch doesn't work (or I can't type at all). I think I've nailed this down when russian layout is chosen there is extra 0x2000 state flag set. I didn't find its meaning perhaps it's part of layout group index. So when I press 'F' on the server with english I got this: ``` [2020-03-29T08:09:45] DEBUG1: event: KeyPress code=41, state=0x0000 [2020-03-29T08:09:45] DEBUG1: onKeyDown id=102 mask=0x0000 button=0x0029 [2020-03-29T08:09:45] DEBUG1: send key down to "vitja-yatop" id=102, mask=0x0000, button=0x0029 [2020-03-29T08:09:45] DEBUG1: new mask: 0x0000 [2020-03-29T08:09:45] DEBUG1: event: KeyRelease code=41, state=0x0000 [2020-03-29T08:09:45] DEBUG1: onKeyUp id=102 mask=0x0000 button=0x0029 [2020-03-29T08:09:45] DEBUG1: send key up to "vitja-yatop" id=102, mask=0x0000, button=0x0029 [2020-03-29T08:09:46] DEBUG1: new mask: 0x0000 ``` With russian locale (and input does not work on the client side): ``` [2020-03-29T08:10:02] DEBUG1: event: KeyPress code=41, state=0x2000 [2020-03-29T08:10:02] DEBUG1: onKeyDown id=1072 mask=0x0000 button=0x0029 [2020-03-29T08:10:02] DEBUG1: send key down to "vitja-yatop" id=1072, mask=0x0000, button=0x0029 [2020-03-29T08:10:02] DEBUG1: new mask: 0x0000 [2020-03-29T08:10:02] DEBUG1: event: KeyRelease code=41, state=0x2000 [2020-03-29T08:10:02] DEBUG1: onKeyUp id=1072 mask=0x0000 button=0x0029 [2020-03-29T08:10:02] DEBUG1: send key up to "vitja-yatop" id=1072, mask=0x0000, button=0x0029 [2020-03-29T08:10:04] DEBUG1: new mask: 0x0000 ``` Client message: ``` [2020-03-29T08:15:06] DEBUG1: recv key down id=0x00000430, mask=0x0000, button=0x0029 [2020-03-29T08:15:06] DEBUG1: mapKey 0430 (1072) with mask 0000, start state: 0000 [2020-03-29T08:15:06] DEBUG1: key 0430 is not on keyboard [2020-03-29T08:15:06] DEBUG1: recv key up id=0x00000430, mask=0x0000, button=0x0029 [2020-03-29T08:15:07] DEBUG1: recv key down id=0x00000430, mask=0x0000, button=0x0029 [2020-03-29T08:15:07] DEBUG1: mapKey 0430 (1072) with mask 0000, start state: 0000 [2020-03-29T08:15:07] DEBUG1: key 0430 is not on keyboard [2020-03-29T08:15:07] DEBUG1: recv key up id=0x00000430, mask=0x0000, button=0x0029 [2020-03-29T08:15:07] DEBUG1: recv key down id=0x00000430, mask=0x0000, button=0x0029 [2020-03-29T08:15:07] DEBUG1: mapKey 0430 (1072) with mask 0000, start state: 0000 [2020-03-29T08:15:07] DEBUG1: key 0430 is not on keyboard [2020-03-29T08:15:07] DEBUG1: recv key up id=0x00000430, mask=0x0000, button=0x0029 ``` Dirty hack with ignoring 0x2000 state flag helped me, see https://github.com/vitek/barrier/commit/cf4fc3334a9aa11ff42fcf4578d614ce3d5f9d13 #### Ubuntu's 16.04 Unity host #### In general problem is the same, barrier is sending current layout keysym. But in this case unity does not use 0x2000 state flag. Keysym mapping occurs inside xcb internals. Here is simple program: ``` #include <X11/Xlib.h> #include <stdio.h> int main() { Display *dpy = XOpenDisplay(NULL); if (!dpy) { perror("XOpenDisplay()"); return 1; } KeySym sym = XkbKeycodeToKeysym(dpy, 42, 0, 0); printf("%d\n", sym); return 0; } ``` In case of unity16.04 result depends on the current layout chosen. In Awesome and in ubuntu 18.04 it doesn't (according to xev they both use 0x2000 flag). So perhaps it's problem of unity16.04. ### Other info Who is responsible for layout switch client or server? Should barrier server send keycodes to the client with respect to the current server's layout? Currently I'm happy with my patch it forces barrier to send english keysyms and X11 on the client side translates it to the client's layout. Anyway I would like to see a clean solution to this problem that would be applied to upstream version.

gitea-mirror commented

2026-05-05 06:29:51 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 26, 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.

@github-actions[bot] commented on GitHub (Sep 26, 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.

No labels

Rows
Columns