keyboard language input change during sessions

[totaam]

Issue migrated from trac ticket # 817

component: client | priority: major | resolution: fixed | keywords: win32

2015-02-24 23:08:29: afarr created the issue

---

Would like the ability to change keyboard language input during the course of a session (English to... say Thai?... then back to English, or what have you, all without disconnecting and re-connecting in order to goose the server into reading the, now changed, settings).

[totaam]

2015-02-25 04:16:58: antoine changed status from new to assigned

[totaam]

2015-02-25 04:16:58: antoine changed component from server to client

[totaam]

2015-02-25 04:16:58: antoine commented

---

This works already for X11 clients.

At the moment, the gtk signal keys-changed does not fire on win32 (or OSX I believe), so we don't update the keymap on the server.

I have a patch that detects the WM_INPUTLANGCHANGE event but there is a big problem with this approach: this is a per-window message on win32, which means that we can have a different input language for each window (easily done with the language bar placed on the desktop).
More documentation: MSDN: About Keyboard Input.

So we cannot just pass the new layout to the server when we get the event, we also have to keep track of which window uses which layout and somehow use the right one. Switching layout is too expensive I think (lots of X11 calls to make), so someone could DOS the server just by alt-tabbing!

Other options:

• use the latest language set for all windows - easy to do
• keep track of the languages used and use a keymap that has them all (limiting the number of active languages to a reasonable limit: 2 or 3?), then we should be able to select the right ones?
• re-write the keyboard layout code (use X11 keyboard API instead of execing new processes #371) to make it fast enough to use (could be useful for the option just above too)
• use input methods to toggle the input language (would need to rely on input methods being present, configured, enabled and actually used by the application..)

Ideas welcome!

[totaam]

2015-02-25 04:17:32: antoine commented

---

Updating milestone: never going to be done for v0.14.x and also unlikely for 0.15.x

[totaam]

2015-02-25 05:20:37: antoine uploaded file win32-keyboard-layout-change.patch (4.7 KiB)

relatively unobtrusive patch

[totaam]

2015-02-25 05:29:30: antoine changed status from assigned to new

[totaam]

2015-02-25 05:29:30: antoine changed owner from antoine to afarr

[totaam]

2015-02-25 05:29:30: antoine commented

---

afarr: good time to get some feedback I think. You can also make a build with the patch above, which does change the keyboard layout globally (the easy option).

[totaam]

2015-02-28 01:16:55: afarr changed status from new to assigned

[totaam]

2015-02-28 01:16:55: afarr commented

---

Testing with the above patch with windows client 0.15.0 8709 against Fedora 20 0.15.0 r8706 - the input switched as expected when switching the language settings on my local machine.

Still looking into needs for a more elegant solution, though I think this will do for the moment (will have to look into the need for an osx patch though).

As a side note, while doing some preliminary testing to see if anything else might be impacted by the patch, I notice that anytime I create a "new" window, whether a browser or a gedit application or just a popup, I'm getting the following message (showing on server side because I have remote-logging enabled... I could check which without if you'd like): failed to set group leader: 'module' object has no attribute 'SHGetPropertyStoreForWindow'

[totaam]

2015-02-28 01:54:50: afarr commented

---

Hmm... also noticed the following on the client-side (apparently because of the remote-logging):

TypeError: standard_logging() takes at least 3 arguments (2 given)
Traceback (most recent call last):
  File "xpra\client\gtk2\gtk2_window_base.pyc", line 123, in on_unrealize
  File "xpra\platform\win32\gui.pyc", line 258, in remove_window_hooks
  File "xpra\log.pyc", line 198, in error
  File "xpra\log.pyc", line 185, in log
  File "xpra\client\ui_client_base.pyc", line 1425, in remote_logging_handler

[totaam]

2015-02-28 02:13:22: antoine commented

---

TypeError: standard_logging() takes at least 3 arguments (2 given)
[[BR]]
Moved to #786#comment:9
[[BR]]

failed to set group leader: 'module' object has no attribute 'SHGetPropertyStoreForWindow'
[[BR]]
See #799.

[totaam]

2015-03-11 02:05:39: afarr changed status from assigned to new

[totaam]

2015-03-11 02:05:39: afarr changed owner from afarr to antoine

[totaam]

2015-03-11 02:05:39: afarr commented

---

Just tested also with osx client (0.15.0 r8769) and found that it supports keyboard language input changes on the fly, even when local applications have focus at the time of the keyboard language input change is made.

This looks good for our purposes... will assign back to you while you ponder a cleaner fix for win32 clients.

[totaam]

2015-06-19 09:38:57: antoine changed status from new to assigned

[totaam]

2015-06-19 09:38:57: antoine commented

---

We can probably merge this as it is - better than nothing?

Once #371 is dealt with, we could just change the layout every time it is needed, as long as the server exposes the new "fast layout change" capability.
We would need to route the keymap changed signal via the window to keep track of the layout each window is meant to be using.

[totaam]

2015-06-28 15:48:52: antoine commented

---

Another option worth exploring is HSHELL_LANGUAGE (Keyboard language was changed or a new keyboard layout was loaded.) / HSHELL_LANGUAGE (A handle to a keyboard layout.) in ShellProc callback function, which we may need to use already for #389.

[totaam]

2015-10-30 11:46:30: antoine uploaded file per-window-layouts.patch (7.5 KiB)

adds code to support different layouts on each window and switch on focus

[totaam]

2015-10-30 11:51:58: antoine changed status from assigned to new

[totaam]

2015-10-30 11:51:58: antoine changed owner from antoine to afarr

[totaam]

2015-10-30 11:51:58: antoine commented

---

Merged the patch in r11099.

I then attempted to add per-window layout support (see patch above), only to find out that contrary to what I thought, the language toolbar seems to apply to all the windows we manage at once and not just the one that has focus. Also tested on win7 with the same result.
It must be looking at the PID rather than window groupings.

@afarr: I believe you had tested this already, and you may even be running with a patched version? The only change worthy of note is #371, which could cause regressions with all keyboard related features.

[totaam]

2015-11-04 01:41:38: afarr commented

---

Just because I was testing for other things, tested with 0.15.8 client (win32)/server (fedora 21) (r11122 client side, r11099 server side)... no luck, but you probably expected that. (I was curious if the patch that had worked previously had been implemented generally...)

• Testing with win client 0.16.0 r11118 against fedora 21 0.16.0 r11122 server... I am failing to switch keyboard input on the fly.

If I connect with an English keyboard setting, then try to change to Hebrew - the keyboard input fails entirely.

If I connect with a Hebrew keyboard setting, then keystrokes are interpreted with Hebrew fonts, then trying to change on the fly back to English, the keystrokes continue to be interpreted/displayed using Hebrew fonts. (Testing our setup, it looks like, for some reason, we haven't merged the patch... thanks for reminding me to test for that.)

Rק-בםממקבאןמע ... oops... Re-connecting with -d keyboard client side...

• With English layout, I typed the letters 'g' & 'h' and got the following:

2015-11-03 16:46:11,461 parse_key_event(<gtk.gdk.Event at 067295C0: GDK_KEY_PRESS keyval=g>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0,
 'string': 'g', 'keyname': 'g', 'pressed': True, 'keyval': 103, 'keycode': 71}>
2015-11-03 16:46:11,463 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': 'g', 'keyname': 'g', 'pressed': True, 'keyval': 103, 'keycode': 71}>) wid=2
2015-11-03 16:46:11,464 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'g', 'keyname': 'g', 'pressed': True, 'keyval
': 103, 'keycode': 71}>)
2015-11-03 16:46:11,612 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 16:46:11,614 parse_key_event(<gtk.gdk.Event at 06729A88: GDK_KEY_RELEASE keyval=g>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group':
 0, 'string': 'g', 'keyname': 'g', 'pressed': False, 'keyval': 103, 'keycode': 71}>
2015-11-03 16:46:11,615 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': 'g', 'keyname': 'g', 'pressed': False, 'keyval': 103, 'keycode': 71}>) wid=2
2015-11-03 16:46:11,617 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'g', 'keyname': 'g', 'pressed': False, 'keyva
l': 103, 'keycode': 71}>)
2015-11-03 16:46:12,707 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 16:46:12,709 parse_key_event(<gtk.gdk.Event at 06729758: GDK_KEY_PRESS keyval=h>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0,
 'string': 'h', 'keyname': 'h', 'pressed': True, 'keyval': 104, 'keycode': 72}>
2015-11-03 16:46:12,709 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': 'h', 'keyname': 'h', 'pressed': True, 'keyval': 104, 'keycode': 72}>) wid=2
2015-11-03 16:46:12,710 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'h', 'keyname': 'h', 'pressed': True, 'keyval
': 104, 'keycode': 72}>)
2015-11-03 16:46:12,851 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 16:46:12,852 parse_key_event(<gtk.gdk.Event at 06729A88: GDK_KEY_RELEASE keyval=h>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group':
 0, 'string': 'h', 'keyname': 'h', 'pressed': False, 'keyval': 104, 'keycode': 72}>
2015-11-03 16:46:12,854 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': 'h', 'keyname': 'h', 'pressed': False, 'keyval': 104, 'keycode': 72}>) wid=2
2015-11-03 16:46:12,854 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'h', 'keyname': 'h', 'pressed': False, 'keyva
l': 104, 'keycode': 72}>)

• Switching, on the fly, to Hebrew and inputting the same keys...

2015-11-03 16:46:26,993 parse_key_event(<gtk.gdk.Event at 067292A8: GDK_KEY_PRESS keyval=hebrew_ayin>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], '
group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True, 'keyval': 3314, 'keycode': 71}>
2015-11-03 16:46:26,993 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True, 'keyval': 3314, 'keycode': 71}>) wid=2
2015-11-03 16:46:26,996 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True
, 'keyval': 3314, 'keycode': 71}>)
2015-11-03 16:46:27,111 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 16:46:27,112 parse_key_event(<gtk.gdk.Event at 06729398: GDK_KEY_RELEASE keyval=hebrew_ayin>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2']
, 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': False, 'keyval': 3314, 'keycode': 71}>
2015-11-03 16:46:27,115 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': False, 'keyval': 3314, 'keycode': 71}>) wid=2
2015-11-03 16:46:27,115 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': Fals
e, 'keyval': 3314, 'keycode': 71}>)
2015-11-03 16:46:27,700 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 16:46:27,700 parse_key_event(<gtk.gdk.Event at 067292A8: GDK_KEY_PRESS keyval=hebrew_yod>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True, 'keyval': 3305, 'keycode': 72}>
2015-11-03 16:46:27,701 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True, 'keyval': 3305, 'keycode': 72}>) wid=2
2015-11-03 16:46:27,703 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True,
 'keyval': 3305, 'keycode': 72}>)
2015-11-03 16:46:27,859 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 16:46:27,861 parse_key_event(<gtk.gdk.Event at 067290C8: GDK_KEY_RELEASE keyval=hebrew_yod>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'],
 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False, 'keyval': 3305, 'keycode': 72}>
2015-11-03 16:46:27,865 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False, 'keyval': 3305, 'keycode': 72}>) wid=2
2015-11-03 16:46:27,867 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False
, 'keyval': 3305, 'keycode': 72}>)
2015-11-03 16:46:29,507 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']

(This time it inputted the same g & h.)

• Meanwhile, if I disconnect, switch the keyboard input to Hebrew, then re-connect and type in the same 'g' & 'h'... I get what looks the same:

2015-11-03 17:25:54,572 parse_key_event(<gtk.gdk.Event at 06729B18: GDK_KEY_PRESS keyval=hebrew_ayin>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], '
group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True, 'keyval': 3314, 'keycode': 71}>
2015-11-03 17:25:54,572 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True, 'keyval': 3314, 'keycode': 71}>) wid=2
2015-11-03 17:25:54,572 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True
, 'keyval': 3314, 'keycode': 71}>)
2015-11-03 17:25:54,713 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 17:25:54,713 parse_key_event(<gtk.gdk.Event at 06729038: GDK_KEY_RELEASE keyval=hebrew_ayin>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2']
, 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': False, 'keyval': 3314, 'keycode': 71}>
2015-11-03 17:25:54,713 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': False, 'keyval': 3314, 'keycode': 71}>) wid=2
2015-11-03 17:25:54,713 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': Fals
e, 'keyval': 3314, 'keycode': 71}>)
2015-11-03 17:25:55,834 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 17:25:55,834 parse_key_event(<gtk.gdk.Event at 06729890: GDK_KEY_PRESS keyval=hebrew_yod>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True, 'keyval': 3305, 'keycode': 72}>
2015-11-03 17:25:55,834 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True, 'keyval': 3305, 'keycode': 72}>) wid=2
2015-11-03 17:25:55,834 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True,
 'keyval': 3305, 'keycode': 72}>)
2015-11-03 17:25:56,006 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-03 17:25:56,006 parse_key_event(<gtk.gdk.Event at 06729890: GDK_KEY_RELEASE keyval=hebrew_yod>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'],
 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False, 'keyval': 3305, 'keycode': 72}>
2015-11-03 17:25:56,006 handle_key_action(GLClientWindow(2 : gtk2.GLWindowBacking(2, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False, 'keyval': 3305, 'keycode': 72}>) wid=2
2015-11-03 17:25:56,006 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False
, 'keyval': 3305, 'keycode': 72}>)

[totaam]

2015-11-04 04:54:31: antoine commented

---

The client should be logging something like this when you switch layouts:

keymap has been changed to 'gb', sending updated mappings to the server
keymap has been changed to 'fr', sending updated mappings to the server
keymap has been changed to 'gb', sending updated mappings to the server

And on the server:

setting keyboard layout to 'gb'
setting keyboard layout to 'fr'

This worked fine during my testing with XP, but with Windows 7 the switching only worked the first few times then it stopped. I will try to take a look as soon as I can, in the meantime, the type of information needed for debugging keyboard issues is documented here: Keyboard.

[totaam]

2015-11-04 23:23:15: afarr commented

---

The keymap & setting keyboard layout output seems to be missing, actually.

Re-testing with 0.16.0 r11122 windows client on a windows 8.1 client against a 0.16.0 r11122 fedora 21 server, with -d keyboard on both sides, I again typed in 'g' & 'h' with a US English keyboard layout setting, then changed the layout setting to Hebrew, and typed in the same two keys (with no idea what Hebrew characters they might actually represent).

• Client side, I don't see any sign of the keymap being changed:

The 'g' & 'h' input looks clear enough:

2015-11-04 12:41:09,684 parse_key_event(<gtk.gdk.Event at 0675C1D0: GDK_KEY_PRESS keyval=g>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0,
 'string': 'g', 'keyname': 'g', 'pressed': True, 'keyval': 103, 'keycode': 71}>
2015-11-04 12:41:09,684 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': 'g', 'keyname': 'g', 'pressed': True, 'keyval': 103, 'keycode': 71}>) wid=3
2015-11-04 12:41:09,686 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'g', 'keyname': 'g', 'pressed': True, 'keyval
': 103, 'keycode': 71}>)
2015-11-04 12:41:09,799 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:09,799 parse_key_event(<gtk.gdk.Event at 0675C1D0: GDK_KEY_RELEASE keyval=g>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group':
 0, 'string': 'g', 'keyname': 'g', 'pressed': False, 'keyval': 103, 'keycode': 71}>
2015-11-04 12:41:09,799 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': 'g', 'keyname': 'g', 'pressed': False, 'keyval': 103, 'keycode': 71}>) wid=3
2015-11-04 12:41:09,799 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'g', 'keyname': 'g', 'pressed': False, 'keyva
l': 103, 'keycode': 71}>)
2015-11-04 12:41:09,846 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:09,846 parse_key_event(<gtk.gdk.Event at 0675C1D0: GDK_KEY_PRESS keyval=h>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0,
 'string': 'h', 'keyname': 'h', 'pressed': True, 'keyval': 104, 'keycode': 72}>
2015-11-04 12:41:09,846 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': 'h', 'keyname': 'h', 'pressed': True, 'keyval': 104, 'keycode': 72}>) wid=3
2015-11-04 12:41:09,846 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'h', 'keyname': 'h', 'pressed': True, 'keyval
': 104, 'keycode': 72}>)
2015-11-04 12:41:09,956 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:09,956 parse_key_event(<gtk.gdk.Event at 0675C1D0: GDK_KEY_RELEASE keyval=h>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group':
 0, 'string': 'h', 'keyname': 'h', 'pressed': False, 'keyval': 104, 'keycode': 72}>
2015-11-04 12:41:09,956 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': 'h', 'keyname': 'h', 'pressed': False, 'keyval': 104, 'keycode': 72}>) wid=3
2015-11-04 12:41:09,956 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'h', 'keyname': 'h', 'pressed': False, 'keyva
l': 104, 'keycode': 72}>)

There is no sign here of keymap changes though, before the next line of the output which does read as being Hebrew characters:

2015-11-04 12:41:20,502 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:20,502 parse_key_event(<gtk.gdk.Event at 0675C890: GDK_KEY_PRESS keyval=hebrew_ayin>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], '
group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True, 'keyval': 3314, 'keycode': 71}>
2015-11-04 12:41:20,502 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True, 'keyval': 3314, 'keycode': 71}>) wid=3
2015-11-04 12:41:20,502 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': True
, 'keyval': 3314, 'keycode': 71}>)
2015-11-04 12:41:20,706 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:20,706 parse_key_event(<gtk.gdk.Event at 0675C638: GDK_KEY_RELEASE keyval=hebrew_ayin>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2']
, 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': False, 'keyval': 3314, 'keycode': 71}>
2015-11-04 12:41:20,706 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': False, 'keyval': 3314, 'keycode': 71}>) wid=3
2015-11-04 12:41:20,706 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_ayin', 'pressed': Fals
e, 'keyval': 3314, 'keycode': 71}>)
2015-11-04 12:41:22,293 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:22,293 parse_key_event(<gtk.gdk.Event at 0675CE78: GDK_KEY_PRESS keyval=hebrew_yod>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True, 'keyval': 3305, 'keycode': 72}>
2015-11-04 12:41:22,293 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True, 'keyval': 3305, 'keycode': 72}>) wid=3
2015-11-04 12:41:22,293 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': True,
 'keyval': 3305, 'keycode': 72}>)
2015-11-04 12:41:22,480 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 12:41:22,480 parse_key_event(<gtk.gdk.Event at 0675CDB8: GDK_KEY_RELEASE keyval=hebrew_yod>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'],
 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False, 'keyval': 3305, 'keycode': 72}>
2015-11-04 12:41:22,480 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), YUV420P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'g
roup': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False, 'keyval': 3305, 'keycode': 72}>) wid=3
2015-11-04 12:41:22,480 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'hebrew_yod', 'pressed': False
, 'keyval': 3305, 'keycode': 72}>)
2015-11-04 12:41:27,029 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']

• Likewise on the server side, I'm seeing no indication of any keyboard setting changes (I'll post the whole batch of output here in one batch):

2015-11-04 12:41:16,525 get_keycode(71, g, ('mod2',)) is_native_keymap=False, found using translation: 42
2015-11-04 12:41:16,527 handle_key(3,True,g,103,42,('mod2',)) keyboard_sync=True
2015-11-04 12:41:16,528 is_modifier(42) not found
2015-11-04 12:41:16,529 handle keycode pressing 42: key g
2015-11-04 12:41:16,529 fake_key(42, True)
2015-11-04 12:41:16,542 scheduling key repeat timer with delay 500 for g / 42
2015-11-04 12:41:16,647 get_keycode(71, g, ('mod2',)) is_native_keymap=False, found using translation: 42
2015-11-04 12:41:16,648 handle_key(3,False,g,103,42,('mod2',)) keyboard_sync=True
2015-11-04 12:41:16,648 is_modifier(42) not found
2015-11-04 12:41:16,648 handle keycode unpressing 42: key g
2015-11-04 12:41:16,649 fake_key(42, False)
2015-11-04 12:41:16,719 get_keycode(72, h, ('mod2',)) is_native_keymap=False, found using translation: 43
2015-11-04 12:41:16,720 handle_key(3,True,h,104,43,('mod2',)) keyboard_sync=True
2015-11-04 12:41:16,720 is_modifier(43) not found
2015-11-04 12:41:16,720 handle keycode pressing 43: key h
2015-11-04 12:41:16,721 fake_key(43, True)
2015-11-04 12:41:16,721 scheduling key repeat timer with delay 500 for h / 43
2015-11-04 12:41:16,838 get_keycode(72, h, ('mod2',)) is_native_keymap=False, found using translation: 43
2015-11-04 12:41:16,839 handle_key(3,False,h,104,43,('mod2',)) keyboard_sync=True
2015-11-04 12:41:16,839 is_modifier(43) not found
2015-11-04 12:41:16,839 handle keycode unpressing 43: key h
2015-11-04 12:41:16,840 fake_key(43, False)
2015-11-04 12:41:27,350 get_keycode(71, hebrew_ayin, ('mod2',)) non-native keymap, translation lookup: 71
2015-11-04 12:41:27,351 handle_key(3,True,hebrew_ayin,3314,71,('mod2',)) keyboard_sync=True
2015-11-04 12:41:27,351 is_modifier(71) not found
2015-11-04 12:41:27,352 handle keycode pressing 71: key hebrew_ayin
2015-11-04 12:41:27,352 fake_key(71, True)
2015-11-04 12:41:27,357 scheduling key repeat timer with delay 500 for hebrew_ayin / 71
2015-11-04 12:41:27,549 get_keycode(71, hebrew_ayin, ('mod2',)) non-native keymap, translation lookup: 71
2015-11-04 12:41:27,549 handle_key(3,False,hebrew_ayin,3314,71,('mod2',)) keyboard_sync=True
2015-11-04 12:41:27,550 is_modifier(71) not found
2015-11-04 12:41:27,550 handle keycode unpressing 71: key hebrew_ayin
2015-11-04 12:41:27,550 fake_key(71, False)
2015-11-04 12:41:29,143 get_keycode(72, hebrew_yod, ('mod2',)) non-native keymap, translation lookup: 72
2015-11-04 12:41:29,144 handle_key(3,True,hebrew_yod,3305,72,('mod2',)) keyboard_sync=True
2015-11-04 12:41:29,144 is_modifier(72) not found
2015-11-04 12:41:29,144 handle keycode pressing 72: key hebrew_yod
2015-11-04 12:41:29,144 fake_key(72, True)
2015-11-04 12:41:29,144 scheduling key repeat timer with delay 500 for hebrew_yod / 72
2015-11-04 12:41:29,319 get_keycode(72, hebrew_yod, ('mod2',)) non-native keymap, translation lookup: 72
2015-11-04 12:41:29,320 handle_key(3,False,hebrew_yod,3305,72,('mod2',)) keyboard_sync=True
2015-11-04 12:41:29,321 is_modifier(72) not found
2015-11-04 12:41:29,321 handle keycode unpressing 72: key hebrew_yod
2015-11-04 12:41:29,322 fake_key(72, False)
2015-11-04 12:41:33,866 _clear_keys_pressed()

• Oddly, the GTK_Keyboard_Test.exe program isn't working client side.

• Testing with the ​gtk_view_keyboard.py inside the session, the keys are being picked with the following values after changing the keyboard setup client side:

down    F5        65474    71    0 0 ['2']
up      F5        65474    71    0 0 ['2']
down    F6        65475    72    0 0 ['2']
up      F6        65475    72    0 0 ['2']

• setxkbmap -print gives the same output both before and after switching the keyboard layout from English to Hebrew:

xkb_keymap {
};

• setxkbmap -query likewise gives the same output before and after the keyboard layout is changed:

rules:    base
layout:   us

• xmodmap -pke also seems to have the same output before and after the layout change (I'm sensing a pattern) - Most interesting is that the keycodes for 71 and 72 are showing the same F5 and F6 values before and after that are being picked up by the gtk_view_keyboard.py tool, but which don't seem to be interpreted on the server side as corresponding to the Hebrew characters that the -d keyboard seems to be recognizing.

Looking back at some references listed above, I do see that the LoadKeyboardLayout function seems to have changed its behavior beginning with windows 8 (https://msdn.microsoft.com/en-us/library/windows/desktop/ms646305(v=vs.85).aspx) ... maybe that was blown as badly as the DPI awareness API functionality?

I see this unanswered question along those lines: http://cboard.cprogramming.com/windows-programming/147317-activatekeyboardlayout-loadkeyboardlayout-not-working.html ... and I see this indicting that some layouts are just not working: http://msdev.developer-works.com/article/31713388/LoadKeyboardLayout()+Api+Is+not+functioning+properly+for+some+input+languages.+

With that in mind, the possibility that it is just the Hebrew going awry crossed my mind (looks like you're testing with French and UK (GB) English) - so I set up for Mexican Spanish ... and experimented until I found that the '[' key, followed by 'e' will output 'é'.

• Connecting with an English layout, then switching to Spanish... there seemed to be no response - the keys were interpreted as '[e' before and after.

• Oddly, connecting with a Spanish layout, then switching to English, I get the 'é' initially, but oddly get '{e' after switching back to English (??).

For some reason, when switching from the Spanish to the English, I see a 'Control_L' key release event on both client and server... perhaps because it is a return to the defined "Native" language?

• Client side, including the preceding e key release and the ... post-ceding bracketleft key press:

2015-11-04 15:04:38,141 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'e', 'keyname': 'e', 'pressed': True, 'keyval
': 101, 'keycode': 69}>)
2015-11-04 15:04:38,309 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 15:04:38,309 parse_key_event(<gtk.gdk.Event at 06739200: GDK_KEY_RELEASE keyval=e>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group':
 0, 'string': 'e', 'keyname': 'e', 'pressed': False, 'keyval': 101, 'keycode': 69}>
2015-11-04 15:04:38,309 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': 'e', 'keyname': 'e', 'pressed': False, 'keyval': 101, 'keycode': 69}>) wid=3
2015-11-04 15:04:38,309 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': 'e', 'keyname': 'e', 'pressed': False, 'keyva
l': 101, 'keycode': 69}>)
2015-11-04 15:04:47,678 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 15:04:47,678 parse_key_event(<gtk.gdk.Event at 06739A88: GDK_KEY_RELEASE keyval=Control_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'],
'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': False, 'keyval': 65507, 'keycode': 17}>
2015-11-04 15:04:47,678 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': '', 'keyname': 'Control_L', 'pressed': False, 'keyval': 65507, 'keycode': 17}>) wid=3
2015-11-04 15:04:47,678 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': False,
 'keyval': 65507, 'keycode': 17}>)
2015-11-04 15:04:49,818 mask_to_names(<flags 0 of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['mod2']
2015-11-04 15:04:49,818 parse_key_event(<gtk.gdk.Event at 06739B60: GDK_KEY_PRESS keyval=bracketleft>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], '
group': 0, 'string': '[', 'keyname': 'bracketleft', 'pressed': True, 'keyval': 91, 'keycode': 219}>
2015-11-04 15:04:49,818 handle_key_action(GLClientWindow(3 : gtk2.GLWindowBacking(3, (910, 680), None)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'grou
p': 0, 'string': '[', 'keyname': 'bracketleft', 'pressed': True, 'keyval': 91, 'keycode': 219}>) wid=3
2015-11-04 15:04:49,818 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '[', 'keyname': 'bracketleft', 'pressed': Tru
e, 'keyval': 91, 'keycode': 219}>)

• Server side, including the same before key release and after key press:

2015-11-04 15:04:45,027 get_keycode(69, e, ('mod2',)) is_native_keymap=False, found using translation: 26
2015-11-04 15:04:45,028 handle_key(3,False,e,101,26,('mod2',)) keyboard_sync=True
2015-11-04 15:04:45,028 is_modifier(26) not found
2015-11-04 15:04:45,028 handle keycode unpressing 26: key e
2015-11-04 15:04:45,028 fake_key(26, False)
2015-11-04 15:04:54,400 get_keycode(17, Control_L, ('mod2',)) is_native_keymap=False, found using translation: 37
2015-11-04 15:04:54,401 handle_key(3,False,Control_L,65507,37,('mod2',)) keyboard_sync=True
2015-11-04 15:04:54,401 handle keycode 37: key Control_L was already unpressed, ignoring
2015-11-04 15:04:56,544 get_keycode(219, bracketleft, ('mod2',)) non-native keymap, translation lookup: 48
2015-11-04 15:04:56,545 handle_key(3,True,bracketleft,91,48,('mod2',)) keyboard_sync=True
2015-11-04 15:04:56,545 is_modifier(48) not found
2015-11-04 15:04:56,546 handle keycode pressing 48: key bracketleft
2015-11-04 15:04:56,546 fake_key(48, True)
2015-11-04 15:04:56,548 scheduling key repeat timer with delay 500 for bracketleft / 48

If the server is ignoring the input to change language, because it thinks that "key" is already unpressed, maybe that's the problem?

[totaam]

2015-11-05 00:33:32: afarr commented

---

Hmm... one more wrinkle - it turns out that, with windows 8.1 at least, the key combo Shift-Alt is a shortcut to change keyboard input layouts.

[totaam]

2015-11-05 09:31:40: antoine commented

---

Oddly, the GTK_Keyboard_Test.exe program isn't working client side.
[[BR]]
Will fix when I get a chance, you can help me by figuring out which revision broke it (no need for a full bisection, even a rough estimate would help).

But it won't be very useful in this case since you don't have layout change events: nothing will work properly without those events.
We need those events to set the correct keymap, without the correct keymap, it doesn't really matter what keys we send.

Please try with other OS releases: XP, win7, .. maybe something has changed?
Also try -d win32 when switching layouts, maybe there is a new/different event we need to look out for.

[totaam]

2015-11-05 20:08:30: afarr commented

---

A quick and dirty bisection with handy win32 clients... looks like 0.16.0 r10504 has a working keyboard tool, but r10513 doesn't.

Testing with 0.16.0 r11122 client on windows 7 (against r11122 0.16 on fedora 21, unsurprisingly) - switching keyboard layouts on the fly seems to work exactly as expected. (Might be a while before I remember to set up an xp machine to test... but I expect it will also work as ... expected.)

Trying again with the windows 8.1 client with -d win32, I'm not seeing anything outputting when I change keyboard input layouts.

On the off chance that there's something of use, here's the server side output when I click the Shift-Alt combination shortcut to change keyboard layouts, with -d keyboard,win32:

2015-11-05 12:01:50,063 get_keycode(18, Alt_L, ('shift', 'mod2')) is_native_keymap=False, found using translation: 64
2015-11-05 12:01:50,064 handle_key(3,True,Alt_L,65513,64,('shift', 'mod2')) keyboard_sync=True
2015-11-05 12:01:50,064 handle keycode pressing 64: key Alt_L
2015-11-05 12:01:50,064 fake_key(64, True)
2015-11-05 12:01:50,284 get_keycode(16, Shift_L, ('mod1', 'mod2')) is_native_keymap=False, found using translation: 50
2015-11-05 12:01:50,284 make_keymask_match(('mod1', 'mod2')) current mask: set(['mod1', 'mod2', 'shift']), wanted: set(['mod1', 'mod2']), ignoring=50/['Shift_L'], keys_pressed={64: 'Alt_L', 50: 'Shift_L'}
2015-11-05 12:01:50,284 is_ignored(shift, set(['Shift_L', 'Shift_R']))=set(['Shift_L'])
2015-11-05 12:01:50,284 modifier shift ignored (in ignored keynames=set(['Shift_L', 'Shift_R']))
2015-11-05 12:01:50,285 handle_key(3,False,Shift_L,65505,50,('mod1', 'mod2')) keyboard_sync=True
2015-11-05 12:01:50,285 handle keycode unpressing 50: key Shift_L
2015-11-05 12:01:50,285 fake_key(50, False)
2015-11-05 12:01:50,310 get_keycode(18, Alt_L, ('mod2',)) is_native_keymap=False, found using translation: 64
2015-11-05 12:01:50,310 make_keymask_match(('mod2',)) current mask: set(['mod1', 'mod2']), wanted: set(['mod2']), ignoring=64/['Alt_L'], keys_pressed={64: 'Alt_L', 50: 'Shift_L'}
2015-11-05 12:01:50,310 is_ignored(mod1, set(['Meta_R', 'Alt_R', 'Meta_L', 'Alt_L']))=set(['Alt_L'])
2015-11-05 12:01:50,310 modifier mod1 ignored (in ignored keynames=set(['Meta_R', 'Alt_R', 'Meta_L', 'Alt_L']))
2015-11-05 12:01:50,311 handle_key(3,False,Alt_L,65513,64,('mod2',)) keyboard_sync=True
2015-11-05 12:01:50,311 handle keycode unpressing 64: key Alt_L
2015-11-05 12:01:50,311 fake_key(64, False)

(Unfortunately, I don't see anything at all if I use the mouse to click the layout setting button on the tray, on either client or server side... though I am seeing the Control_L unpress key event whenever I close the pop up after switching the layout.)

[totaam]

2015-11-09 10:32:32: antoine uploaded file win8.png (221.0 KiB)

change of language detected with windows 8.1

[totaam]

2015-11-09 11:04:52: antoine commented

---

A quick and dirty bisection with handy win32 clients... looks like 0.16.0 r10504 has a working keyboard tool, but r10513 doesn't.
[[BR]]
Many thanks for that, the changesets in between were easy to skip through and there is only one that stood out: r10512. Turns out, we can't change the colour of a blackhole - makes sense! r11160 fixes that.

Tested on my win8.1 VM and I do see the keyboard change event, see:
[[Image(win8.png)]].

I triggered this using the language systray menu in the bottom right of the screen (showing "FRA" in that screenshot), maybe you're doing it differently?

This also gets triggered if I use Alt_L + Shift. (which makes me think that maybe we should change our own default shortcuts to try to avoid triggering this language change inadvertently)

During testing I did find a checkbox under Language / Advance Settings under Switching input methods which reads Let me set a different input method for each app window. So I am moving support for this feature to #1027 (so the patch I wrote above is not all wasted effort after all)

[totaam]

2015-11-09 23:44:40: afarr commented

---

I am now very confused.

It sounds like you are using the same method to change input settings as I am (that little code by the clock/date ... and otherwise the Alt_L + Shift). It looks like you are using the same OS (windows 8.1 ... those icons look the same as mine). Are you, by chance, also using a bootcamped mac-mini?

• As one experiment, I tried to also "Add a language" to add Fench - but I don't see the keymap change with a change to FRA any more than I do with... whatever those Hebrew characters are.

• As another experiment, I tried with --opengl=off, a long shot which also failed to payoff - still no sign of a keymap change.

Updated to 0.16.0 r11159 client side, 0.16.0 r11160 on the fedora 21 server ... all same results.

• Went crazy and actually used the "Options" link to fully download the updates for Spanish (rather than just whatever setting the control panel supports without actually doing a download/install)... which actually made my icons look more like yours - but again, no sign of keymap change.

(Neither switching using shift-alt, nor using the button, is being caught to trigger a keymap change, and neither the Spanish which I fully installed nor the French which I just set up, nor the Hebrew that's so much more dramatic to test with, is being successfully input - but in each case the -d keyboard output seems to be recognizing what the keymapping should be. I can't for the life of me think of what I might've done with this system to make it behave differently than yours. I'll have to see about finding another 8.1 to compare with?)

[totaam]

2015-11-10 03:16:23: afarr commented

---

... Well, I Shanghai'd another 8.1 system, and it DID show the keymap changes when changing keyboard layout (in this case to Hebrew, just because it was the most dramatic of tests, and successfully installed fonts on server).

I suppose, by the law of "the best two out of three", this ticket can be closed.

That said... any ideas of what tests I might run to see why my machine isn't kicking out a hook that the server/client can grab onto? (is it because it's a bootcamped mac mini maybe?)

[totaam]

2015-11-10 18:15:20: maxmylyn commented

---

Tested with my Bootcamp'd Macbook Pro(running Win8.1):

• r11152 Win8.1 client against a r11152 Fedora 21 server

• Can swap between Hebrew and English on the fly...all is working well.

It appears that the problem is limited to, as afarr politely put it, "afarr's POS computer".

[totaam]

2015-11-13 00:27:24: maxmylyn commented

---

Continued testing with a 11178 Win8.1 Client against a Fedora 21 11178 Server ([http://xpra.org/beta] for both):

• Installed Russian (ru_RU) on the server, and added the Russian keyboard layout to Windows

• Cannot switch to and type in Russian on the fly.

• Connecting with the English (Int/normal/'Apple') layout enabled (ENG US on the taskbar next to the clock) , then hitting shift + alt to switch to Russian does not work. My letter key inputs become what I assume are 10-key inputs, only allowing numbers, +, -, /, * and a couple of the character inputs

• Connecting with the Russian layout enabled (РУС in the bottom right), I can type in Russian characters, but am unable to switch to English with shift + alt

• Disconnected, and reconnected back in English, and typing works fine, unless I use shift and a character...at which point it goes back into Russian(?!?)

---

It appears the problem has spread to my laptop as well.

[totaam]

2015-11-13 01:30:22: antoine changed owner from afarr to maxmylyn

[totaam]

2015-11-13 01:30:22: antoine commented

---

Please provide the log output using -d win32 so we can look for messages.
(and maybe the server log if there are any messages at all when changing layout, or at least the 2 different startup messages with the 2 different layouts)

[totaam]

2015-11-13 23:07:10: maxmylyn uploaded file 817 -d win32.txt (17.9 KiB)

Requested -d win32 output. It outputted A LOT. Unforunately, it has been trimmed to the last little bits by Windows.

[totaam]

2015-11-13 23:07:52: maxmylyn uploaded file 817 server output.txt (1.5 KiB)

Server output. Not a lot interesting...but who knows. (of note: never prints layout changes)

[totaam]

2015-11-13 23:08:19: maxmylyn commented

---

Attached requested logs.

Same versions and computers.

[totaam]

2015-11-13 23:47:35: afarr commented

---

Uhhh... testing some scaling, I missed the '+' key... and now my machine IS changing configurations on the fly.

I am seeing a traceback when I do it though... so maybe forcing encodings triggered (or, in this case un-triggered?) a bug - and I'm not just losing my mind.

---

First traceback I saw, which I triggered while testing scaling issues, never repeated, so I'm not at all sure it has anything to do with the keyboard input... but after I saw this, the keyboard input switching on the fly started working.

2015-11-13 09:35:08,625 received updated display dimensions
2015-11-13 09:35:08,625 client display size is 3413x1440 with 1 screen:
2015-11-13 09:35:08,626   2\WinSta-Default (1354x571 mm - DPI: 64x64) workarea: 3413x1413
2015-11-13 09:35:08,626     DISPLAY1 2560x1440 at 853x0 (621x341 mm - DPI: 104x107) workarea: 2560x1413
2015-11-13 09:35:08,626     DISPLAY2 853x480 (597x336 mm - DPI: 36x36) workarea: 853x425
2015-11-13 09:35:08,740 DPI set to 64 x 64
2015-11-13 09:35:08,742 sent updated screen size to 1 client: 3904x1440 (max 8192x4096)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/x11/server.py", line 825, in _process_unmap_window
    assert not window.is_OR()
AssertionError

• About 3 minutes later, I apparently keystroked the (shift-alt) shortcut - and my keyboard layout change was recognized!

2015-11-13 09:38:10,478 received updated display dimensions
2015-11-13 09:38:10,478 client display size is 3413x1440 with 1 screen:
2015-11-13 09:38:10,479   2\WinSta-Default (1354x571 mm - DPI: 64x64) workarea: 3413x1413
2015-11-13 09:38:10,479     DISPLAY1 2560x1440 at 853x0 (621x341 mm - DPI: 104x107) workarea: 2560x1413
2015-11-13 09:38:10,479     DISPLAY2 853x480 (597x336 mm - DPI: 36x36) workarea: 853x425
2015-11-13 09:38:10,765 DPI set to 64 x 64
2015-11-13 09:38:10,788 sent updated screen size to 1 client: 3904x1440 (max 8192x4096)
2015-11-13 09:38:40,501 setting keyboard layout to 'il'
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
>                   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
2015-11-13 09:38:40,556 setting keyboard layout to 'il'
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
>                   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server

At this point, keyboard input continues to work on the fly, but I am getting this traceback whenever it does so. (0.16.0 r11185 windows client and fedora 21 server.)

[totaam]

2015-11-14 04:52:16: antoine changed owner from maxmylyn to afarr

[totaam]

2015-11-14 04:52:16: antoine commented

---

Uhhh... testing some scaling, I missed the '+' key... and now my machine IS changing configurations on the fly.
[[BR]]
What "+" key?? I thought it was just Shift and Alt. Do you also need +?
Are you testing scaling or keyboard layout switching? (me confused)

[[BR]]

so maybe forcing encodings triggered
[[BR]]
What forcing encodings?
[[BR]]

---

First traceback I saw, which I triggered while testing scaling issues, never repeated, so I'm not at all sure it has anything to do with the keyboard input... but after I saw this, the keyboard input switching on the fly started working.
[[BR]]
This is unrelated, it must have been triggered when you have an OR window (ie: drop down menu) and you change the desktop scaling. It should not have had any other effect, certainly nothing related to keyboard input.
Should be fixed in r11212.

---

@afarr: can you liase with maxmylyn to figure out what is different between those setups you have since one is switching and the other one is not.
Are you trying to switch using keys exclusively? Or through the systray widget? Or through the control panel? None of them work? Compare OS, settings, etc..

[totaam]

2016-01-07 01:58:13: afarr changed owner from afarr to antoine

[totaam]

2016-01-07 01:58:13: afarr commented

---

At this point, neither maxmylyn nor I can re-introduce the failure to switch keyboard input detection on the fly with windows systems.

We are, in fact, collectively mystified as to what had been going wrong. For some reason my system resisted switching on the fly for a long time, but once it started respecting the switching, I haven't been able to figure out what had changed, or anything that can return it back to the non-switching behavior.

Maxmylyn's system was working as expected immediately when testing the fixes, but there was one client (or maybe server) that didn't work, but nothing he's been able to think to try has reproduced whatever it was that happened with his system.

No, I don't like mysteries like this either.

In our collective efforts to reproduce this, maxmylyn noticed that he could get errors, and occasionally disconnections, if he mashed keyboard keys while the server was in the process of processing the change of keyboard input (maybe block keyboard input while the server is switching layout? display a keyboard icon of some sort to indicate to users that it will be a moment while the server switches?).

In my efforts to try the same, in case my system would behave differently, while testing with a 0.17.0 r11588 windows client against a 0.16.1 r11607 fedora 23 server, I managed to get some keyboard loading error messages server side, but (to the best of my knowledge with some newly installed fonts more successfully than other newly installed ones) wasn't able to reproduce whatever failures I was one having with my system switching layouts.

Some of the server errors, in case there's anything interesting (I kind of doubt it):

2016-01-06 17:41:29,320 setting keyboard layout to 'il'
2016-01-06 17:41:29,331 Error loading new keyboard description
2016-01-06 17:41:29,743 setting keyboard layout to 'latam'
2016-01-06 17:41:29,758 Error loading new keyboard description
2016-01-06 17:41:29,796 setting keyboard layout to 'latam'
2016-01-06 17:41:29,809 Error loading new keyboard description
2016-01-06 17:41:44,840 setting keyboard layout to 'in'
2016-01-06 17:41:44,857 Error loading new keyboard description
2016-01-06 17:41:44,959 setting keyboard layout to 'in'
2016-01-06 17:41:44,988 Error loading new keyboard description
2016-01-06 17:41:45,032 set_keycodes: no free keycodes!, cannot translate -1: (('U+0939', 0), ('U+0919', 1))
2016-01-06 17:41:45,033 set_keycodes: no free keycodes!, cannot translate -1: (('U+0929', 1), ('U+0928', 0))
2016-01-06 17:41:45,033 set_keycodes: no free keycodes!, cannot translate -1: (('U+0948', 0), ('U+0910', 1))
2016-01-06 17:41:45,033 set_keycodes: no free keycodes!, cannot translate -1: (('U+0902', 0), ('U+0950', 3), ('U+0901', 1))
2016-01-06 17:41:45,033 set_keycodes: no free keycodes!, cannot translate -1: (('U+092C', 0), ('U+092D', 1))
2016-01-06 17:41:45,034 set_keycodes: no free keycodes!, cannot translate -1: (('U+0946', 0), ('U+090E', 1), ('U+0953', 2))
2016-01-06 17:41:45,035 set_keycodes: no free keycodes!, cannot translate -1: (('U+091B', 1), ('U+091A', 0), ('U+0952', 2))
2016-01-06 17:41:45,035 set_keycodes: no free keycodes!, cannot translate -1: (('U+0944', 2), ('U+0943', 0), ('U+090B', 1), ('U+0960', 3))
2016-01-06 17:41:45,036 set_keycodes: no free keycodes!, cannot translate -1: (('U+095F', 1), ('U+092F', 0))
2016-01-06 17:41:45,036 set_keycodes: no free keycodes!, cannot translate -1: (('U+0912', 1), ('U+094A', 0))
2016-01-06 17:41:45,037 set_keycodes: no free keycodes!, cannot translate -1: (('U+095C', 2), ('U+0921', 0), ('U+095D', 3), ('U+0922', 1))
2016-01-06 17:41:45,037 set_keycodes: no free keycodes!, cannot translate -1: (('U+0911', 1), ('U+0949', 0))
2016-01-06 17:41:45,037 set_keycodes: no free keycodes!, cannot translate -1: (('U+093C', 0), ('U+091E', 1))
2016-01-06 17:41:45,037 set_keycodes: no free keycodes!, cannot translate -1: (('U+091F', 0), ('U+0951', 3), ('U+0920', 1))
2016-01-06 17:41:45,038 set_keycodes: no free keycodes!, cannot translate -1: (('U+0911', 1), ('U+0949', 0))

2016-01-06 17:42:23,530 setting keyboard layout to 'fr'
2016-01-06 17:42:23,542 Error loading new keyboard description
2016-01-06 17:42:23,590 set_keycodes: no free keycodes!, cannot translate -1: (('U+090F', 1), ('U+0947', 0))
2016-01-06 17:42:23,591 set_keycodes: no free keycodes!, cannot translate -1: (('U+0942', 0), ('U+090A', 1))
2016-01-06 17:42:23,592 set_keycodes: no free keycodes!, cannot translate -1: (('U+0939', 0), ('U+0919', 1))
2016-01-06 17:42:23,592 set_keycodes: no free keycodes!, cannot translate -1: (('U+0929', 1), ('U+0928', 0))
2016-01-06 17:42:23,592 set_keycodes: no free keycodes!, cannot translate -1: (('U+0948', 0), ('U+0910', 1))
2016-01-06 17:42:23,592 set_keycodes: no free keycodes!, cannot translate -1: (('U+0902', 0), ('U+0950', 3), ('U+0901', 1))
2016-01-06 17:42:23,592 set_keycodes: no free keycodes!, cannot translate -1: (('U+092C', 0), ('U+092D', 1))
2016-01-06 17:42:23,593 set_keycodes: no free keycodes!, cannot translate -1: (('U+0946', 0), ('U+090E', 1), ('U+0953', 2))
2016-01-06 17:42:23,597 set_keycodes: no free keycodes!, cannot translate -1: (('U+091B', 1), ('U+091A', 0), ('U+0952', 2))
2016-01-06 17:42:23,597 set_keycodes: no free keycodes!, cannot translate -1: (('U+0944', 2), ('U+0943', 0), ('U+090B', 1), ('U+0960', 3))
2016-01-06 17:42:23,597 set_keycodes: no free keycodes!, cannot translate -1: (('U+095F', 1), ('U+092F', 0))
2016-01-06 17:42:23,598 set_keycodes: no free keycodes!, cannot translate -1: (('U+0912', 1), ('U+094A', 0))
2016-01-06 17:42:23,598 set_keycodes: no free keycodes!, cannot translate -1: (('U+095C', 2), ('U+0921', 0), ('U+095D', 3), ('U+0922', 1))
2016-01-06 17:42:23,598 set_keycodes: no free keycodes!, cannot translate -1: (('U+0911', 1), ('U+0949', 0))
2016-01-06 17:42:23,599 set_keycodes: no free keycodes!, cannot translate -1: (('U+093C', 0), ('U+091E', 1))
2016-01-06 17:42:23,599 set_keycodes: no free keycodes!, cannot translate -1: (('U+091F', 0), ('U+0951', 3), ('U+0920', 1))
2016-01-06 17:42:23,599 set_keycodes: no free keycodes!, cannot translate -1: (('U+0911', 1), ('U+0949', 0))
2016-01-06 17:42:23,618 setting keyboard layout to 'fr'
2016-01-06 17:42:23,624 Error loading new keyboard description
2016-01-06 17:42:29,252 setting keyboard layout to 'us'
2016-01-06 17:42:29,326 Error loading new keyboard description
2016-01-06 17:42:29,369 set_keycodes: no free keycodes!, cannot translate -1: (('Page_Down', 0),)
2016-01-06 17:42:29,375 set_keycodes: no free keycodes!, cannot translate -1: (('exclam', 0), ('section', 1))
2016-01-06 17:42:29,399 setting keyboard layout to 'us'
2016-01-06 17:42:29,404 Error loading new keyboard description
2016-01-06 17:42:29,451 set_keycodes: no free keycodes!, cannot translate -1: (('Page_Down', 0),)
2016-01-06 17:42:39,487 setting keyboard layout to 'il'
2016-01-06 17:42:39,497 Error loading new keyboard description
2016-01-06 17:42:39,551 set_keycodes: no free keycodes!, cannot translate -1: (('Page_Down', 0),)
2016-01-06 17:42:39,600 setting keyboard layout to 'il'
2016-01-06 17:42:39,605 Error loading new keyboard description
2016-01-06 17:42:39,644 set_keycodes: no free keycodes!, cannot translate -1: (('Page_Down', 0),)
2016-01-06 17:42:39,645 set_keycodes: no free keycodes!, cannot translate -1: (('E', 1), ('U+05B8', 2), ('hebrew_kuf', 0))
2016-01-06 17:42:39,648 set_keycodes: no free keycodes!, cannot translate -1: (('rightsinglequotemark', 2), ('greater', 1), ('hebrew_taf', 0), ('leftsinglequotemark', 3))
2016-01-06 17:44:04,804 setting keyboard layout to 'us'
2016-01-06 17:44:04,812 Error loading new keyboard description
2016-01-06 17:44:04,868 set_keycodes: no free keycodes!, cannot translate -1: (('Page_Down', 0),)
2016-01-06 17:44:04,870 set_keycodes: no free keycodes!, cannot translate -1: (('E', 1), ('U+05B8', 2), ('hebrew_kuf', 0))
2016-01-06 17:44:04,872 set_keycodes: no free keycodes!, cannot translate -1: (('rightsinglequotemark', 2), ('greater', 1), ('hebrew_taf', 0), ('leftsinglequotemark', 3))
2016-01-06 17:44:04,904 setting keyboard layout to 'us'
2016-01-06 17:44:04,910 Error loading new keyboard description
2016-01-06 17:44:04,943 set_keycodes: no free keycodes!, cannot translate -1: (('Page_Down', 0),)

Assuming that there's nothing interesting there, I think we can close this ticket - whatever quirk I'd stumbled across seems to be fixed (I can open a new ticket if it can ever be reproduced).

[totaam]

2016-03-16 07:20:32: antoine changed status from new to closed

[totaam]

2016-03-16 07:20:32: antoine set resolution to fixed

[totaam]

2016-03-16 07:20:32: antoine commented

---

Closing, will follow up in #1027.