On some Win clients (& some Windows VM shells run on Mac) the Caps Lock and the Num Lock don't work. More info. to follow.
Don't forget to read wiki/Keyboard. VMs are tricky because the VM layer will already do its own keyboard translation, so best avoided if possible when tracking things down.
With windows 7 (not working Caps Lock & Num Lock): keyboard mappings
CAPS LOCK ON DOWN VOIDSYMBOL 16777215 20 0 0 ['L'] UP VOIDSYMBOL 16777215 20 0 0 ['L'] caps lock off down VoidSymbol 16777215 20 0 0 [] up VoidSymbol 16777215 20 0 0 [] Num Lock on down Num_Lock 65407 144 0 0 [] up Num_Lock 65407 144 0 0 [] Num Lock off (same) Shift down Shift_L 65505 16 0 0 ['S'] up Shift_L 65505 16 0 0 [] With the Num Lock on the Num Pad gives down/up KP_1 1 65457 97 0 0 [] down/up KP_2 2 65458 98 0 0 [] (etc.) With the Num Lock off, Num Pad gives down/up End 65367 35 0 0 [] down/up Down 65364 40 0 0 [] down/up Page_Down 65366 34 0 0 [] down/up Left 65361 37 0 0 [] down/up Clear 65291 12 0 0 [] down/up Right 65363 39 0 0 [] down/up Home 65360 36 0 0 [] down/up Up 65362 38 0 0 [] down/up Page_Up 65365 33 0 0 [] (1-9)
I got these results with 2 different (windows) keyboards.
Trying with a mac w/ mac keyboard (on which cap and num lock also don't work with xpra) I got the same results for the caps lock and the Num Lock off. The mac keyboard had no Num Lock proper, I suppose the Num Pad is *supposed* to always be "locked".
With an ubuntu client (& a Fedora server), with the same windows keyboards, caps and num lock both work perfectly (though I can't seem to find a gtk_clipboard_test to see what the key reading is for the caps or num locks that works).
On Linux the keyboard test app is called xpra/gtk_view_keyboard.py
and is installed in the python packages tree.
Can you include some regular keypresses before and after the caps lock
changes.
Here's how things work on win32: we ignore the caps/num-lock keys presses and when the next keypress comes in, the modifiers (shown on the right as ['L']
) should have 'L'
in them. The server will then set caps lock on (or off if the flag is now missing) before processing the key.
Ok, on an ubuntu client's keyboard I get the following results.
(No Num Lock []) 1 down/up KP_End 65436 87 0 0 [] 2 down/up KP_Down 65433 88 0 0 [] 3 down/up KP_Page_Down 65435 89 0 0 [] 4 down/up KP_Left 65430 83 0 0 [] 5 down/up KP_Begin 65437 84 0 0 [] 6 down/up KP_Right 65432 85 0 0 [] 7 down/up KP_Home 65429 79 0 0 [] 8 down/up KP_Up 65431 80 0 0 [] 9 down/up KP_Page_Up 65434 81 0 0 [] 0 down/up KP_Insert 65438 90 0 0 [] (Yes Num Lock ['mod2']) 1 down/up KP_1 1 65457 87 0 0 ['2'] 2 down/up KP_2 2 65458 88 0 0 ['2'] 3 down/up KP_3 3 65459 89 0 0 ['2'] 4 down/up KP_4 4 65460 83 0 0 ['2'] 5 down/up KP_5 5 65461 84 0 0 ['2'] 6 down/up KP_6 6 65462 85 0 0 ['2'] 7 down/up KP_7 7 65463 79 0 0 ['2'] 8 down/up KP_8 8 65464 80 0 0 ['2'] 9 down/up KP_9 9 65465 81 0 0 ['2'] 0 down/up KP_0 0 65456 90 0 0 ['2'] (No Caps Lock, Num Lock yes) a down/up a a 97 38 0 0 ['2'] b down/up b b 98 56 0 0 ['2'] c down/up c c 99 54 0 0 ['2'] v down/up v v 118 55 0 0 ['2'] n down/up n n 110 57 0 0 ['2'] (Shift ['Shift'], Num Lock yes) down Shift_L 65505 50 1 0 ['2'] A down/up A A 65 38 0 0 ['2', 'S'] up Shift_L 65505 50 1 0 ['2', 'S'] down Shift_R 65506 62 1 0 ['2'] B down/up B B 66 56 0 0 ['2', 'S'] up Shift_R 65506 62 1 0 ['2', 'S'] down Shift_L 65505 50 1 0 ['2'] C down C C 67 54 0 0 ['2', 'S'] up Shift_L 65505 50 1 0 ['2', 'S'] up c c 99 54 0 0 ['2'] down Shift_L 65505 50 1 0 ['2'] V down/up V V 86 55 0 0 ['2'] up Shift_L 65505 50 1 0 ['2', 'S'] down Shift_L 65505 50 1 0 ['2'] N down/up N N 78 57 0 0 ['2', 'S'] up Shift_L 65505 50 1 0 ['2', 'S'] (Caps Lock ['Lock'], Num Lock yes) A down/up A A 65 38 0 0 ['2', 'L'] B down/up B B 66 56 0 0 ['2', 'L'] C down/up C C 67 54 0 0 ['2', 'L'] V down/up V V 86 55 0 0 ['2', 'L'] N down/up N N 78 57 0 0 ['2', 'L']
Can you please post the same logs (great formatting job!) on the broken setups (primarily interested with Windows clients - macs are, ahem, "difficult"): not just the modifier key itself, but a pair of few keypresses for each case (say A
and Z
for capslock and 0
and -
for numlock), both before and after setting capslock/numlock.
Ok, a more complete list of Windows 7 keyboard responses:
DOWN VOIDSYMBOL 16777215 20 0 0 ['L'] UP VOIDSYMBOL 16777215 20 0 0 ['L'] down/up A A 65 65 0 0 ['L'] down/up B B 66 66 0 0 ['L'] down/up C C 67 67 0 0 ['L'] down/up Z Z 90 90 0 0 ['L'] down/up N N 78 78 0 0 ['L'] down/up M M 77 77 0 0 ['L']
down VoidSymbol 16777215 20 0 0 [] up VoidSymbol 16777215 20 0 0 [] down/up a a 97 65 0 0 [] down/up b b 98 66 0 0 [] down/up c c 99 67 0 0 [] down/up z z 122 90 0 0 [] down/up n n 110 78 0 0 [] down/up m m 109 77 0 0 []
down Num_Lock 65407 144 0 0 [] up Num_Lock 65407 144 0 0 [] down/up KP_0 0 65456 96 0 0 [] down/up KP_1 1 65457 97 0 0 [] down/up KP_2 2 65458 98 0 0 [] down/up KP_3 3 65459 99 0 0 [] down/up KP_4 4 65460 100 0 0 [] down/up KP_9 9 65465 105 0 0 [] down/up KP_Divide / 65455 111 0 0 [] down/up KP_Subtract - 65453 109 0 0 [] (With caps lock back on) down/up KP_5 5 65461 101 0 0 ['L'] down/up KP_7 7 65463 103 0 0 ['L']
down/up Num_Lock 65407 144 0 0 [] (['L'] w/Caps Lock) (0) down/up Insert 65379 45 0 0 [] (1) down/up End 65367 35 0 0 [] (2) down/up Down 65364 34 0 0 [] (3) down/up Page_Down 65366 34 0 0 [] (4) down/up Left 65361 37 0 0 [] (5) down/up Clear 65291 12 0 0 [] (6) down/up Right 65363 39 0 0 [] (7) down/up Home 65360 36 0 0 [] (8) down/up Up 65362 38 0 0 [] (9) down/up Page_up 65365 33 0 0 [] (/) down/up KP_Divide / 65455 111 0 0 [] (*) down/up KP_Multiply * 65450 106 0 0 [] (-) down/up KP_Subtract - 65453 109 0 0 []
down Shift_L 65505 16 0 0 ['S'] up Shift_L 65505 16 0 0 [] down Shift_L 65505 16 0 0 ['S'] down/up K K 75 75 0 0 ['S'] up Shift_L 65505 16 0 0 [] down Shift_R 65506 161 0 0 ['S'] down/up S S 83 83 0 0 ['S'] up Shift_R 65506 161 0 0 [] down Shift_L 65505 16 0 0 ['S'] down/up H H 72 72 0 0 ['S'] up Shift_L 65505 16 0 0 [] down Shift_R 65506 161 0 0 ['S'] down W W 87 87 0 0 ['S'] up Shift_R 65506 161 0 0 [] up w w 119 87 0 0 []
Opening gtk_view_clipboard in xterm on xpra session attached with Windows 7 client:
down/up g g 103 42 0 0 [] down/up a a 97 38 0 0 [] down Shift_L 65505 50 1 0 ['2'] down/up A A 65 38 0 0 ['2', 'S'] up Shift_L 65505 50 1 0 ['2', 'S'] down Shift_R 65506 62 1 0 ['2'] down/up M M 77 58 0 0 ['2', 'S'] up Shift_R 65506 62 1 0 ['2', 'S']
Num Lock --> ['mod2']
down Num_Lock 65407 77 1 0 [] up Num_Lock 65407 77 1 0 ['2']
(Actually, this portion I'm typing into an xpra window... and the Num Lock seems to be working fine now. 789)
FYI some background: the code specifically ignores the VoidSymbol
/ 16777215
combination as the keypresses don't have the modifiers correctly set on win32, and we rely on the key presses that follow to set the numlock/capslock if needed.
OK, so for capslock it looks like the client is sending the modifier correctly (['L']
) so the server should know what to do: set capslock before processing the keypress.
But with XPRA_KEYBOARD_DEBUG=1
, I see that in fact the server does not have the modifier in its list:
make_keymask_match: ignored - current mask=[]
So it gets lost somewhere between the client keypress event and the server's make_keymask_match
.
KP_0
... KP_9
, KP_Divide
, KP_Multiply
, KP_Substract
and KP_Add
. And that's the easy part, knowing which modifier to set is harder... sigh.
I think you missed the last comment I put in.
(Actually, this portion I'm typing into an xpra window... and the Num Lock seems to be working fine now. 789)
With the latest beta Win client Num Lock seems to work consistently.
Looks like half the headache just went away (though maybe it is a mystery what fixed it). *Cheers*
And now it comes back to me (this is old stuff - so old I can't find the changeset that clashed), the "make_keymask_match: ignored
" message is actually telling us that the server just does not bother trying to make modifiers match with win32 clients (as trying to make the win32 keymap match an X11 keymap is an exercise in futility when it comes to modifiers), and so even the capslock modifier is ignored... which is not what we want.
r3029 fixes that (server side) - this is some really ugly code overall, but it works.
Please test and close this ticket if all good.
All good. Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/287