debauchee / barrier

Open-source KVM software
Other
27.23k stars 1.5k forks source link

Keyboard layout issue #603

Open vitek opened 4 years ago

vitek commented 4 years ago

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.

github-actions[bot] commented 3 years ago

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.