Keyboard Layout issue with Windows Shadow Server

[totaam]

Issue migrated from trac ticket # 1099

component: server | priority: major | resolution: fixed

2016-01-26 18:19:49: maxmylyn created the issue

---

Using a Windows 8.1 64-bit trunk r11738 Shadow Server, and connecting from a Fedora 23 r11763 client:

• Most character keys work.

• The only working symbol keys are period (next to right shift)

• Left and right arrow keys act as the Win key, activating the start menu(or going to that awful Metro interface sometimes - focus issue that Classic Shell has).

Perusing the -d keyboard logs show that the client and the server receive all keyboard input commands, and the server recognizes them as correct. However, it shows the symbol keys as "ignored". In addition, the arrow keys come in correct, but input as the Win key. I'll attach -d keyboard client and server logs to demonstrate. They're kinda long, but show that the server recognizes most symbol keys sent by the client.

[totaam]

2016-01-26 18:21:27: maxmylyn uploaded file 1099 Keyboard client output.txt (33.1 KiB)

Client -d keyboard output.

[totaam]

2016-01-26 18:23:16: maxmylyn uploaded file 1099 keyboard server log.txt (16.3 KiB)

-d keyboard on the server output

[totaam]

2016-01-26 18:28:48: antoine changed status from new to assigned

[totaam]

2016-01-26 18:28:48: antoine commented

---

In the future, please try to include the log files without line wrapping. (before putty messes it up)

[totaam]

2016-02-29 10:46:06: antoine changed status from assigned to new

[totaam]

2016-02-29 10:46:06: antoine changed owner from antoine to maxmylyn

[totaam]

2016-02-29 10:46:06: antoine commented

---

Should be fixed in r12103. (will backport)

I may still need to add key definitions from the full list, as per [http://www.theasciicode.com.ar/ascii-printable-characters/backslash-reverse-slash-ascii-code-92.html]

@maxmylyn: thanks for the report, please close if this works for you.

This ticket is tracked in #389.

[totaam]

2016-03-02 01:10:01: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2016-03-02 01:10:01: maxmylyn commented

---

Upped to r12103:

• Arrow keys working fine now

• Still unable to enter symbols - keyboard logs look the same

• Oddly enough, the period (.), and asterisk (*) keys work on the 10-key - other than that, no symbols only characters.

• Unable to use shift + arrow to highlight text

• Upper case works (shift + letter)

[totaam]

2016-03-02 01:26:22: antoine changed status from new to assigned

[totaam]

2016-03-02 01:26:22: antoine commented

---

DOH, didn't think of testing that. Thanks.
I think we'll have to cook the keynames both numlock / non numlock case.

[totaam]

2016-03-03 22:29:48: maxmylyn commented

---

@antoine:

Please note (in case I wasn't clear enough) that NO symbols are working - this includes symbols on the entire keyboard NOT just the 10-key. (quotes, brackets, shift + number keys, etc etc)

[totaam]

2016-04-16 16:36:41: antoine changed status from assigned to new

[totaam]

2016-04-16 16:36:41: antoine changed owner from antoine to maxmylyn

[totaam]

2016-04-16 16:36:41: antoine commented

---

Not sure how I ever got them to work - maybe I didn't?
r12399 fixes it. Will follow up in #1172.

@maxmylyn: I really hope we can close this one now..

[totaam]

2016-04-21 18:31:12: maxmylyn commented

---

Unable to test - see #1184 for details.

(Shadow Servers currently broken)

[totaam]

2016-04-22 03:46:54: antoine commented

---

Should be unblocked, see #1184#comment:1.

[totaam]

2016-04-22 18:39:23: maxmylyn commented

---

Testing with the same r12401:

• The ENG-US/INTL layout works mostly fine.

I get almost all the character keys to line up properly. The single quite key types a ```(the tildé key), and backslash types ', and the tildé key types nothing at all.

• Switching to ENG-Apple (this is an Apple laptop...), all the symbol keys line up.

With the Apple keyboard layout selected, the - key on the 10-key does not work. Other than that, every other character works as expected. (Same behavior as the ENG-Apple on the other machine)

• Connecting to another machine, this one a normal NON APPLE Windows machine:

The default keyboard layout works exactly perfect, except the - key on the 10-key does not work.

---

Also, while testing this, I found that x264 breaks when the server has a 4k display....so I'll be filing that ticket soon.

[totaam]

2016-04-23 06:15:36: antoine commented

---

I cannot reproduce this when using the same layout (us or uk) at both ends. I don't have a US keyboard layout, but I know where the keys are meant to be and I can also look them up here: [https://upload.wikimedia.org/wikipedia/commons/5/51/KB_United_States-NoAltGr.svg] - though some of them are in a completely different location on a UK layout: [https://upload.wikimedia.org/wikipedia/commons/d/da/KB_United_Kingdom.svg], in particular the backslash key and tilde keys.. which happen to be some of the problematic ones. Pressing them in Fedora does give the correct key symbols.

Note: when shadowing, we do not change the server-side keyboard layout, so when the client and server layout differ, some keys may get mapped wrong, or not at all.. This may be improved in a future release, added to #1172.
Even more so when you use the language bar to set different keyboard layouts for different windows: the shadow server will pickup the keyboard layout which is set when it is launched and will not be aware the layout used in other windows.

Debug output (merged client and server with remote logging, trimmed to show just the keypress part, removing intermediary log messages):

• single-quote:

send_key_action(1, <GTKKeyEvent object, contents: \
    {'modifiers': [], 'group': 0, 'string': "'", 'keyname': 'apostrophe', \
     'pressed': True, 'keyval': 39, 'keycode': 48}>)
handle keycode pressing 222: key apostrophe

• tilde:

send_key_action(1, <GTKKeyEvent object, contents: \
    {'modifiers': [], 'group': 0, 'string': '`', 'keyname': 'grave', \
     'pressed': True, 'keyval': 96, 'keycode': 49}>)
handle keycode pressing 192: key grave

• backslash:

send_key_action(1, <GTKKeyEvent object, contents: \
    {'modifiers': [], 'group': 0, 'string': '\\', 'keyname': 'backslash', \
     'pressed': True, 'keyval': 92, 'keycode': 51}>)
handle keycode pressing 220: key backslash

Please provide the "-d keyboard" debug output for just the problematic keys.

[totaam]

2016-04-26 21:28:12: maxmylyn commented

---

Okay, I am confused and a little concerned now. I updated my client to 12482, and left the server (Windows Machine) at the same version, and now all the keys are lining up, except for the Apple Layout, which types the single quote key for the tilde key, and the single quote key types the backslash key. Using shift on those keys types the upper case version of the other key.

The ENG-US and ENG-INTL are also working fine now (minus the - key on the 10-key), furthering my confusion. I'll attach a log of the not working - key. As for the other keys:

Do you still want the logs for the misbehaving keys? Even though they are now misbehaving on other keys.

---

Of note:

While testing this, I found that when a UAC prompt pops up (for the uninformed, the "This application would like to make changes blah blah" popup), I am completely unable to use the session anymore until I physically move the keyboard and mouse on the machine to accept or decline the prompt. Also, I'm unable to send keyboard or mouse events while the elevated application has focus. (Further, I cannot click or send keyboard events to the elevated window) I have a feeling Windows does this intentionally. Just a caveat for anyone reading this.

---

Also of note:

The control and shift plus the arrow keys intermittently does not work to highlight text (control + shift + arrow should select "words" of text at a time). It started out not working when I was writing this comment, but now that I'm here it's working fine. Weird.

[totaam]

2016-04-26 21:30:07: maxmylyn uploaded file 1099_missing_dash.txt (25.7 KiB)

connected, hit dash a few times into Pnotepad, then disconnected and killed the server

[totaam]

2016-04-26 21:31:06: maxmylyn uploaded file 1099_missing_dash_client.txt (75.7 KiB)

same as the other missing dash, but this time the client logs

[totaam]

2016-05-22 07:28:35: antoine commented

---

Thanks for the logs, the problem was pretty obvious:

get_keycode(82, 'KP_Subtract', ('mod2',))=-1

Turns out to be a tricky combination of bugs: a typo then a logic error, fixed in r12641 (large change because I had to change the data structure) - will backport.

I don't think there's anything we can do about the UAC thing as the moment, only if we implement the deep privileged hooks in #389#comment:11.

As for control+shift issues, we can try to fix those if they re-appear.

[totaam]

2016-05-23 17:12:39: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2016-05-23 17:12:39: maxmylyn commented

---

Updated the Windows Shadow Server to r12647 and the Fedora 23 Client to r12659:

• All character keys work except the Enter key on the 10-key.

I get the following output from -d keyboard:

2016-05-23 09:16:18,533 get_keycode(104, 'KP_Enter', ('mod2',))=-1
2016-05-23 09:16:18,533 make_keymask_match(('mod2',), -1, ['KP_Enter'])
2016-05-23 09:16:18,533 keys pressed=
2016-05-23 09:16:18,533 make_keymask_match: current mask=set([]), wanted=set(['mod2']), ignoring=-1/['KP_Enter']
2016-05-23 09:16:18,658 get_keycode(104, 'KP_Enter', ('mod2',))=-1
2016-05-23 09:16:18,658 make_keymask_match(('mod2',), -1, ['KP_Enter'])
2016-05-23 09:16:18,658 keys pressed=
2016-05-23 09:16:18,658 make_keymask_match: current mask=set([]), wanted=set(['mod2']), ignoring=-1/['KP_Enter']

But, all other keys work fine with no issue. It'll even let me type with a Russian keyboard layout....although I couldn't tell you if they lined up correctly as I don't have a Russian keyboard...or speak Russian...

Anyways, passing back to you.

---

[[br]]

I don't think there's anything we can do about the UAC thing as the moment

[[br]]

Yeah, I'm not surprised. If you really need Xpra as a VNC-type setup, you'll have to disable UAC prompts all together.

Also of note:

• Running Xpra in an "Elevated Command Prompt" (ugh I feel dirty using Microsoft lingo) will allow you to interact with other "elevated" applications. So, at least there's an easy enough workaround.

  • Start > Command Prompt > right click and click "Run as Administrator"

[totaam]

2016-05-24 04:51:41: antoine changed status from new to closed

[totaam]

2016-05-24 04:51:41: antoine set resolution to fixed

[totaam]

2016-05-24 04:51:41: antoine commented

---

Thanks for testing!
Just one key missing, how hard can it be...
But as I couldn't figure out how to send the enter key ([https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html] Enter is 0xE01C), I've used the return key in r12660, which should work just as well for most applications.

Closing.