xpra icon
Bug tracker and wiki

#1099 closed defect (fixed)

Keyboard Layout issue with Windows Shadow Server

Reported by: J. Max Mena Owned by: Antoine Martin
Priority: major Milestone: 0.17
Component: server Version: trunk
Keywords: Cc:

Description

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.

Attachments (4)

1099 Keyboard client output.txt (33.1 KB) - added by J. Max Mena 18 months ago.
Client -d keyboard output.
1099 keyboard server log.txt (16.3 KB) - added by J. Max Mena 18 months ago.
-d keyboard on the server output
1099_missing_dash.txt (25.7 KB) - added by J. Max Mena 15 months ago.
connected, hit dash a few times into Pnotepad, then disconnected and killed the server
1099_missing_dash_client.txt (75.7 KB) - added by J. Max Mena 15 months ago.
same as the other missing dash, but this time the client logs

Download all attachments as: .zip

Change History (18)

Changed 18 months ago by J. Max Mena

Client -d keyboard output.

Changed 18 months ago by J. Max Mena

-d keyboard on the server output

comment:1 Changed 18 months ago by Antoine Martin

Status: newassigned

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

comment:2 Changed 17 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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.

Last edited 16 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 17 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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)

comment:4 Changed 17 months ago by Antoine Martin

Status: newassigned

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

comment:5 Changed 17 months ago by J. Max Mena

@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)

comment:6 Changed 16 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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..

comment:7 Changed 15 months ago by J. Max Mena

Unable to test - see #1184 for details.

(Shadow Servers currently broken)

comment:8 Changed 15 months ago by Antoine Martin

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

comment:9 Changed 15 months ago by J. Max Mena

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.

comment:10 Changed 15 months ago by Antoine Martin

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.

comment:11 Changed 15 months ago by J. Max Mena

Okay, I am confused and a little concerned now. I updated my client to r12482, 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.

Changed 15 months ago by J. Max Mena

Attachment: 1099_missing_dash.txt added

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

Changed 15 months ago by J. Max Mena

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

comment:12 Changed 14 months ago by Antoine Martin

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 ticket:389#comment:11.

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

comment:13 Changed 14 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.



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


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"

comment:14 Changed 14 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.