With osx clients, xpra 0.11.0 (and probably all before) the numpad is not recognized in an xpra session (numpad keys are interpreted like arrow keys).
I'm attaching xpra session keyboard tool output and osx local keyboard tool output.
Xpra session numpad output
osx local numpad output
In the local output, I can see that you pressed: 1,2,3,...
What about the xpra session output, what did you press there? (seems completely random, Alt, Escape, KP_Begin, KP_5, Alt, Shift, Numlock, ...)
Can you give me matching outputs instead?
And if possible, without any pressed modifiers. A separate single keypad keypress would help too.
Improved Xpra session numpad output
found as part of KeyRemap4MacBook on github
Please read Apple KB PH3986.
From this page and many others on the subject, it appears that many different things can get in the way of using the numpad - and we want to ensure whatever solution we come up with will work in most cases:
Clear" key - it may need to be combined with "Shift" and/or "Control" to do anything..
F6"
using "control" + "shift" + "f6" for "numlock" makes any sense - I failed at this last one.
etc
xpra numpad output from win keyboard (same as mac keyboard...)
xpra osx keyboard output - command key insight
Attached file of numpad output with windows keyboard - looks essentially the same as that from a mac keyboard.
Interestingly, the command key tests for another ticket about to be filed revealed that xpra considers the command key to be a numlock key for one keystroke. I attached that as well, and will also attach it to the command v. control ticket to be made, as it seems relevant for both.
Please see comment:2, I need to know what those keys do, if anything.
Also, the latest attachment seems to imply the keyboard tool was used from inside xpra? I need raw data, without xpra interfering.
osx local environment numpad key mappings
Attached a file of local numpad key mappings.
always set numlock as being on
OK, so there does not seem to be any difference between "num-locked" state and "non-num-locked" state. At least none that I can see.
Moreover, even with a keyboard that has a numlock key ("windows keyboard"), pressing the key shows up as:
down/up Escape 65307 71 0 0 []
Is this the same value that you get when you press the actual "Escape" key?
It would be nice if we could emulate the numlock switching (even if we end up doing the reverse of what the client machine has set 50% of the time...)
The osx-numlock.patch may help, if it does then the fix can be backported to v0.10.x safely. If possible, please try the integrated patch from #456 - if that works then this is what will get used.
Works-for-me(tm)
In my VM, I find that escape comes up as:
down/up Escape 65307 53 0 0 []
And numlock is as above (71), please confirm what you are seeing on a real keyboard/mac. It looks like the two keys do send a different keycode (53 vs 71) and so we could implement a software toggle if needed (not sure how we can find the 71 value without hardcoding it though..).
Ideally, we would just get the correct modifier mask from gtk... which should be possible: cocoa HandlingKeyEvents refers to NSNumericPadKeyMask and I can see in AppKit:
AppKit.NSNumericPadKeyMask = 0x200000
This may require a patch to gtk2.
I can confirm - on laptop built-in keyboard, external mac keyboard, and external microsoft keyboard - one and all - I get the same escape key mapping that you got with your VM.
I'll see about a build to test the patch in #456... though without Smo I'm not sure if we have patch building skills enough.
Testing with 0.11-r4748 - the numpad works and the clear button allows the numlock to be "toggled" off/on as well. Nice work.
Applied numlock change only to v0.10.x branch in r4750.
r4751 adds a menu entry for toggling numlock state - this allows us to get in sync with the actual numlock state if we guess wrong (since we have no way of detecting the correct startup state)
If needed, we could improve on this in the future by:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/453