Using a Windows 8.1 64-bit trunk r11738 Shadow Server, and connecting from a Fedora 23 r11763 client:
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.
Client -d keyboard output.
-d keyboard on the server output
In the future, please try to include the log files without line wrapping. (before putty messes it up)
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.
Upped to r12103:
.
), and asterisk (*
) keys work on the 10-key - other than that, no symbols only characters.
shift + arrow
to highlight text
shift + letter
)
DOH, didn't think of testing that. Thanks. I think we'll have to cook the keynames both numlock / non numlock case.
@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)
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..
Unable to test - see #1184 for details.
(Shadow Servers currently broken)
Should be unblocked, see ticket:1184#comment:1.
Testing with the same r12401:
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.
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)
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.
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/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):
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
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
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.
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.
connected, hit dash a few times into Pnotepad, then disconnected and killed the server
same as the other missing dash, but this time the client logs
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.
Updated the Windows Shadow Server to r12647 and the Fedora 23 Client to r12659:
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:
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1099