Xpra: Ticket #453: keyboard numpad doesn't work with osx client

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.

Wed, 06 Nov 2013 02:14:44 GMT - alas: attachment set

Xpra session numpad output

Wed, 06 Nov 2013 02:16:02 GMT - alas: attachment set

osx local numpad output

Wed, 06 Nov 2013 02:33:48 GMT - Antoine Martin: owner changed; keywords, milestone set

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.

Thu, 07 Nov 2013 23:25:55 GMT - alas: attachment set

Improved Xpra session numpad output

Fri, 08 Nov 2013 06:52:36 GMT - Antoine Martin: attachment set

found as part of KeyRemap4MacBook on github

Fri, 08 Nov 2013 06:53:01 GMT - 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:


Sat, 09 Nov 2013 02:50:05 GMT - alas: attachment set

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

Sat, 09 Nov 2013 02:51:26 GMT - alas: attachment set

xpra osx keyboard output - command key insight

Sat, 09 Nov 2013 02:53:32 GMT - 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.

Mon, 11 Nov 2013 02:19:29 GMT - 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.

Wed, 13 Nov 2013 00:58:39 GMT - alas: attachment set

osx local environment numpad key mappings

Wed, 13 Nov 2013 01:05:17 GMT - alas:

Attached a file of local numpad key mappings.

Wed, 13 Nov 2013 05:51:12 GMT - Antoine Martin: attachment set

always set numlock as being on

Wed, 13 Nov 2013 05:53:21 GMT - 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.


Wed, 13 Nov 2013 08:44:11 GMT - 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.

Wed, 13 Nov 2013 18:58:45 GMT - 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.

Fri, 15 Nov 2013 01:13:33 GMT - 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.

Fri, 15 Nov 2013 04:55:16 GMT - Antoine Martin: status changed; resolution set

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:

Sat, 23 Jan 2021 04:55:58 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/453