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
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.
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.
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.
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:
With russian locale (and input does not work on the client side):
Client message:
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:
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.