keyboard numpad doesn't work with osx client

[alas]

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.

[alas]

Xpra session numpad output

[alas]

osx local numpad output

[Antoine Martin]

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.

[alas]

Improved Xpra session numpad output

[Antoine Martin]

found as part of KeyRemap4MacBook on github

[Antoine Martin]

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:

• try collecting keyboard data with the "Clear" key - it may need to be combined with "Shift" and/or "Control" to do anything..
• same with "F6"
• as per the link, try the settings ("mouse keys")
• maybe different OSX versions behave differently too (we should not care about anything older than Lion)
• if googling, try not to get frustrated at the moronic mac fanbois shouting "mac it's easy" whist claiming that using "control" + "shift" + "f6" for "numlock" makes any sense - I failed at this last one.

etc

[alas]

xpra numpad output from win keyboard (same as mac keyboard...)

[alas]

xpra osx keyboard output - command key insight

[alas]

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.

[Antoine Martin]

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.

[alas]

osx local environment numpad key mappings

[alas]

Attached a file of local numpad key mappings.

• osx 10.6.8 laptop keys - the F6 function did create a numpad, but converted m j k l u i o 7 8 9 into a numpad... when converted back was just part of keyboard (included a full mapping in each case).

• osx 10.6.8 and 10.9 with external mac and external windows keyboards. Both behaved the same.

• I had no success with clear, shift, ctrl, command &/or F6... in any combination... causing the numpads of the external keyboards to behave as if the numlock was off. Keystrokes for various experiments are included in the doc, and I did test each combination with both osx 10.6.8 and 10.9 - behaved exactly the same in every case.

[Antoine Martin]

always set numlock as being on

[Antoine Martin]

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)

[Antoine Martin]

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.

[alas]

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.

[alas]

Testing with 0.11-r4748 - the numpad works and the clear button allows the numlock to be "toggled" off/on as well. Nice work.

[Antoine Martin]

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:

• fixing gtk builds to give us the correct numlock state
• detecting numlock state ourselves