#453 closed defect (fixed)
keyboard numpad doesn't work with osx client
| Reported by: | alas | Owned by: | alas |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.11 |
| Component: | client | Version: | |
| Keywords: | osx | Cc: |
Description
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.
Attachments (8)
Change History (19)
Changed 7 years ago by
| Attachment: | numPad-osx-0-10-8-r4595-keyboardTest added |
|---|
Changed 7 years ago by
| Attachment: | osx_local_numpad_keyboard_output.txt added |
|---|
osx local numpad output
comment:1 Changed 7 years ago by
| Keywords: | osx added |
|---|---|
| Milestone: | → 0.11 |
| Owner: | changed from Antoine Martin to alas |
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.
Changed 7 years ago by
| Attachment: | NumLock-xpra-session-output_xpra_0-11r4707-client_4625-server_ added |
|---|
Improved Xpra session numpad output
Changed 7 years ago by
| Attachment: | KeyCode.data.txt added |
|---|
found as part of KeyRemap4MacBook on github
comment:2 Changed 7 years ago by
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
Changed 7 years ago by
| Attachment: | xpra_win_numpad_output added |
|---|
xpra numpad output from win keyboard (same as mac keyboard...)
Changed 7 years ago by
| Attachment: | xpra_keyboard_output_control-v-command added |
|---|
xpra osx keyboard output - command key insight
comment:3 Changed 7 years ago by
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.
comment:4 Changed 7 years ago by
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.
Changed 7 years ago by
| Attachment: | osx_local_numpad_testings.txt added |
|---|
osx local environment numpad key mappings
comment:5 Changed 7 years ago by
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.
comment:6 Changed 7 years ago by
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)
comment:7 Changed 7 years ago by
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.
comment:8 Changed 7 years ago by
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.
comment:9 Changed 7 years ago by
Testing with 0.11-r4748 - the numpad works and the clear button allows the numlock to be "toggled" off/on as well. Nice work.
comment:10 Changed 7 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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
comment:11 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/453
copyleft 2010 - 2021
Xpra session numpad output