Xpra: Ticket #287: Win client Caps Lock state not forwarded

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.



Sat, 09 Mar 2013 04:01:17 GMT - Antoine Martin:

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.


Wed, 13 Mar 2013 03:25:44 GMT - alas:

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).


Wed, 13 Mar 2013 03:36:02 GMT - Antoine Martin: owner changed

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.


Tue, 19 Mar 2013 00:53:57 GMT - alas:

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']

Tue, 19 Mar 2013 06:40:41 GMT - Antoine Martin:

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.


Tue, 19 Mar 2013 21:41:01 GMT - alas:

Ok, a more complete list of Windows 7 keyboard responses:


Opening gtk_view_clipboard in xterm on xpra session attached with Windows 7 client:

(Actually, this portion I'm typing into an xpra window... and the Num Lock seems to be working fine now. 789)


Wed, 20 Mar 2013 16:35:24 GMT - Antoine Martin: owner, status changed

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.


Wed, 20 Mar 2013 17:28:15 GMT - alas:

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*


Wed, 20 Mar 2013 17:32:56 GMT - Antoine Martin: owner, status, summary changed

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.


Wed, 20 Mar 2013 18:50:16 GMT - alas: status changed; resolution set

All good. Closing.


Sat, 23 Jan 2021 04:50:38 GMT - migration script:

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