Split from #566
afarr: please confirm and provide details. You should be able to find lists with multiple items selectable using a browser.
Confirmed. Running osx client 0.12.5 r6328 against a fedora 19 server 0.13.0 r6398.
Cmd-click (in place of ctrl-click) on a select list fails to pick a second item on the list, instead selecting the newly clicked item in place of the previously selected item (ctrl-click works as expected with windows clients).
With -d keyboard
the output client side is as follows:
2014-05-08 14:02:50,786 mask_to_names(<flags GDK_BUTTON5_MASK of type GdkModifierType>)=['mod2'] 2014-05-08 14:02:50,790 mask_to_names(<flags GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2'] 2014-05-08 14:02:50,889 mask_to_names(<flags GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2'] 2014-05-08 14:02:56,206 mask_to_names(<flags 0 of type GdkModifierType>)=['mod2'] 2014-05-08 14:02:56,207 parse_key_event(<gtk.gdk.Event at 0xb589758: GDK_KEY_PRESS keyval=Meta_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}> 2014-05-08 14:02:56,207 handle_key_action(GLClientWindow(3 : GLPixmapBacking(3, (1440, 856), YUV444P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>) wid=3 2014-05-08 14:02:56,207 swap keys: translating key '<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>' to (59, 'Control_L') 2014-05-08 14:02:56,207 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65511, 'keycode': 59}>)
2014-05-08 14:02:58,609 mask_to_names(<flags GDK_MOD2_MASK | GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2']
2014-05-08 14:03:04,865 mask_to_names swapping meta for control: mod1 for control 2014-05-08 14:03:04,865 mask_to_names(<flags GDK_MOD2_MASK | GDK_META_MASK of type GdkModifierType>)=['mod2', 'control'] 2014-05-08 14:03:04,865 parse_key_event(<gtk.gdk.Event at 0xb589d10: GDK_KEY_RELEASE keyval=Meta_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}> 2014-05-08 14:03:04,865 handle_key_action(GLClientWindow(3 : GLPixmapBacking(3, (1440, 856), YUV444P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>) wid=3 2014-05-08 14:03:04,866 swap keys: translating key '<GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>' to (59, 'Control_L') 2014-05-08 14:03:04,866 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': False, 'keyval': 65511, 'keycode': 59}>)
2014-05-08 14:02:56,232 get_keycode(59, Control_L, ('mod2',)) is_native_keymap=False, found using translation: 37 2014-05-08 14:02:56,233 handle_key(3,True,Control_L,65511,37,('mod2',)) keyboard_sync=False 2014-05-08 14:02:56,233 handle keycode pressing 37: key Control_L 2014-05-08 14:02:56,233 fake_key(37, True) 2014-05-08 14:02:56,234 handle keycode unpressing 37: key Control_L 2014-05-08 14:02:56,234 fake_key(37, False) 2014-05-08 14:03:04,891 get_keycode(59, Control_L, ('mod2', 'control')) is_native_keymap=False, found using translation: 37 2014-05-08 14:03:04,891 make_keymask_match(('mod2', 'control')) current mask: set(['mod2']), wanted: set(['control', 'mod2']), ignoring=37/['Control_L'], keys_pressed={} 2014-05-08 14:03:04,891 modifier ignored (ignored keyname=Control_L) 2014-05-08 14:03:04,891 modifier control ignored (in ignored keynames=set(['Control_L', 'Control_R'])) 2014-05-08 14:03:04,891 handle_key(3,False,Control_L,65511,37,('mod2', 'control')) keyboard_sync=False 2014-05-08 14:03:04,892 handle keycode 37: key Control_L was already unpressed, ignoring
I assume there's just something missing client-side when the mouse clicks occur while the cmd button is depressed? (I'll try with windows client as well and post anything significantly different.)
With windows client 0.12.5 r6398 against same server, -d keyboard
, I get this output when clicking with the ctrl button pressed:
2014-05-08 14:52:08,911 mask_to_names(<flags GDK_CONTROL_MASK of type GdkModifierType>) GetKeyState(VK_NUMLOCK)=1, names=['control', 'mod2'] 2014-05-08 14:52:08,913 parse_key_event(<gtk.gdk.Event at 038BBCF8: GDK_KEY_PRESS keyval=Control_L>, True)=<GTKKeyEvent object, contents: {'modifiers': ['control', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65507, 'keycode': 17}> 2014-05-08 14:52:08,914 handle_key_action(GLClientWindow(3 : GLPixmapBacking(3, (1092, 632), GBRP)), <GTKKeyEvent object, contents: {'modifiers': ['control', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65507, 'keycode': 17}>) wid=3 2014-05-08 14:52:08,914 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['control', 'mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65507, 'keycode': 17}>)
Should I repeat with -d mouse
as well?
Despite virtualbox often getting in the way of testing, I was able to use control + click with OSX as long as I disable Control / Option Key Swap. Can you confirm that this also works for you?
First question: you talk about "Cmd
", I assume you mean the Command
key? But the swapping is meant to be for the Option
key instead. Either the swap is wrong or your description of what you did is. Which one is it?
Since the key press event does get translated into Control_L
(see swap keys: translating key ...
), I assume that you are pressing the key that is swapped with control (whichever one it is...)
Next, as per ticket:456#comment:10, the modifiers mask is also meant to be translated:
mask_to_names swapping meta for control: mod1 for control
But I see no sign of this here, you posted:
mask_to_names(<flags GDK_MOD2_MASK | GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2']
The start of the debug logging also contains some information of interest about which keys are mapped to control and meta, you would have seen a stacktrace in the logs - this is fixed in r6421. Please post the lines showing (edited):
set_modifier_mappings(..) meta=mod1, control=control, numlock=mod2 set_modifier_mappings(..) swap keys translations={'Meta_R': (59, 'Control_L'), \ 'Control_L': (55, 'Alt_L'), 'Meta_L': (59, 'Control_L'), 'Control_R': (54, 'Alt_R')}
r6422 adds more debug logging to mask_to_names
.
r6426 adds details in xpra info
about which keys and modifiers are pressed under "keyboard.state
" (obviously, you have to schedule it or use another machine to run it)
Please post some debug logging again with these changes.
Question 0: Yes, when I click to disable the Control/ Option Key Swap I am able to use the control + click to select multiple items from a select list.
First question: Yes, I was abbreviating Command
with Cmd
(took a google search to realize why there might've been confusion... I'll type the extra keystrokes in the future...)
Option
key that swaps, I tried a Command + C
on some text and compared with a Option + C
... the Command + c copied text out of the xpra session (I am well practiced at working with the clipboard bugginess on osx) ... but the Option + C didn't. Together with the fact that OSX generally uses Command where everything else uses Control, I think we can be pretty certain that it is indeed the Command, and not the Option, key which we switched with the Control key. (The only things that I know the Option key does on OSX are to produce alternate characters for given keys... such as Option + e outputting an accent, ยด, and so on. Is there some other functionality I'm not aware of that made you think we ought to be switching the Option key, rather than the Command key, with the Control key?)
I haven't had a chance to get an updated client to test with just yet, but I have some output from my previous combination for you for now (including a traceback that I didn't notice before):
2014-05-09 15:59:42,614 set_modifier_mappings({'control': (((59, 'Control_L'), 'Control_L'), ('Control_R', 'Control_R')), 'mod1': (((55, 'Alt_L'), 'Alt_L'), ((58, 'Alt_L'), 'Alt_L'), ((54, 'Alt_R'), 'Alt_R'), ('Meta_R', 'Alt_R'), ('Alt_L', 'Alt_L'), ('Meta_L', 'Meta_L')), 'mod2': (('Num_Lock', 'Num_Lock'),), 'mod3': ((115, 'Super_L'), ('Super_R', 'Super_R'), ('Super_L', 'Super_L')), 'mod4': (('Hyper_L', 'Hyper_L'), ('Hyper_R', 'Hyper_R')), 'mod5': (('Mode_switch', 'Mode_switch'), ('ISO_Level3_Shift', 'ISO_Level3_Shift')), 'shift': (('Shift_L', 'Shift_L'), ((60, 'Shift_R'), 'Shift_R')), 'lock': (((57, 'Caps_Lock'), 'Caps_Lock'),)}) 2014-05-09 15:59:42,615 modifier_keys={'ISO_Level3_Shift': 'mod5', 'Mode_switch': 'mod5', 'Meta_L': 'mod1', 'Control_R': 'control', 'Super_R': 'mod3', 'Alt_R': 'mod1', 'Hyper_L': 'mod4', 'Caps_Lock': 'lock', 'Hyper_R': 'mod4', 'Alt_L': 'mod1', 'Num_Lock': 'mod2', 'Super_L': 'mod3', 'Shift_R': 'shift', 'Shift_L': 'shift', 'Control_L': 'control'} 2014-05-09 15:59:42,615 modifier_keycodes={'ISO_Level3_Shift': ['ISO_Level3_Shift'], 'Mode_switch': ['Mode_switch'], 'Meta_L': ['Meta_L'], 'Control_R': ['Control_R'], 'Super_R': ['Super_R'], 'Alt_R': [(54, 'Alt_R'), 'Meta_R'], 'Hyper_L': ['Hyper_L'], 'Caps_Lock': [(57, 'Caps_Lock')], 'Hyper_R': ['Hyper_R'], 'Alt_L': [(55, 'Alt_L'), (58, 'Alt_L'), 'Alt_L'], 'Num_Lock': ['Num_Lock'], 'Super_L': [115, 'Super_L'], 'Shift_R': [(60, 'Shift_R')], 'Shift_L': ['Shift_L'], 'Control_L': [(59, 'Control_L')]} Traceback (most recent call last): File "logging/__init__.pyc", line 851, in emit File "logging/__init__.pyc", line 724, in format formatwarningRR?RRR$R?categoryRORUtfiletlineRR((slogging/__init__.pyct _showwarning?s cCsL|r*tdrHtjatt_qHntdk rHtt_dandS(s? File "logging/__init__.pyc", line 464, in format File "logging/__init__.pyc", line 328, in getMessage A handler class which writes logging records, appropriately formatted, TypeError: not all arguments converted during string formatting Logged from file log.py, line 143 2014-05-09 15:59:42,627 set_modifier_mappings(..) swap keys translations={'Meta_R': (59, 'Control_L'), 'Control_L': (55, 'Alt_L'), 'Meta_L': (59, 'Control_L'), 'Control_R': (54, 'Alt_R')}
I'll try to see about installing the updated osx client from your beta list and getting new output, though I'm not sure if there's a new fedora rpm handy for me.
Using osx 0.13.0 r6427 (your beta) against the same fedora 19 server (r6398) I am seeing the following initial mappings client-side:
2014-05-09 17:21:45,917 set_modifier_mappings({'control': (((59, 'Control_L'), 'Control_L'), ('Control_R', 'Control_R')), 'mod1': (((55, 'Alt_L'), 'Alt_L'), ((58, 'Alt_L'), 'Alt_L'), ((54, 'Alt_R'), 'Alt_R'), ('Meta_R', 'Alt_R'), ('Alt_L', 'Alt_L'), ('Meta_L', 'Meta_L')), 'mod2': (('Num_Lock', 'Num_Lock'),), 'mod3': ((115, 'Super_L'), ('Super_R', 'Super_R'), ('Super_L', 'Super_L')), 'mod4': (('Hyper_L', 'Hyper_L'), ('Hyper_R', 'Hyper_R')), 'mod5': (('Mode_switch', 'Mode_switch'), ('ISO_Level3_Shift', 'ISO_Level3_Shift')), 'shift': (('Shift_L', 'Shift_L'), ((60, 'Shift_R'), 'Shift_R')), 'lock': (((57, 'Caps_Lock'), 'Caps_Lock'),)}) 2014-05-09 17:21:45,917 modifier_keys={'ISO_Level3_Shift': 'mod5', 'Mode_switch': 'mod5', 'Meta_L': 'mod1', 'Control_R': 'control', 'Super_R': 'mod3', 'Alt_R': 'mod1', 'Hyper_L': 'mod4', 'Caps_Lock': 'lock', 'Hyper_R': 'mod4', 'Alt_L': 'mod1', 'Num_Lock': 'mod2', 'Super_L': 'mod3', 'Shift_R': 'shift', 'Shift_L': 'shift', 'Control_L': 'control'} 2014-05-09 17:21:45,917 modifier_keycodes={'ISO_Level3_Shift': ['ISO_Level3_Shift'], 'Mode_switch': ['Mode_switch'], 'Meta_L': ['Meta_L'], 'Control_R': ['Control_R'], 'Super_R': ['Super_R'], 'Alt_R': [(54, 'Alt_R'), 'Meta_R'], 'Hyper_L': ['Hyper_L'], 'Caps_Lock': [(57, 'Caps_Lock')], 'Hyper_R': ['Hyper_R'], 'Alt_L': [(55, 'Alt_L'), (58, 'Alt_L'), 'Alt_L'], 'Num_Lock': ['Num_Lock'], 'Super_L': [115, 'Super_L'], 'Shift_R': [(60, 'Shift_R')], 'Shift_L': ['Shift_L'], 'Control_L': [(59, 'Control_L')]} 2014-05-09 17:21:45,918 set_modifier_mappings({'control': (((59, 'Control_L'), 'Control_L'), ('Control_R', 'Control_R')), 'mod1': (((55, 'Alt_L'), 'Alt_L'), ((58, 'Alt_L'), 'Alt_L'), ((54, 'Alt_R'), 'Alt_R'), ('Meta_R', 'Alt_R'), ('Alt_L', 'Alt_L'), ('Meta_L', 'Meta_L')), 'mod2': (('Num_Lock', 'Num_Lock'),), 'mod3': ((115, 'Super_L'), ('Super_R', 'Super_R'), ('Super_L', 'Super_L')), 'mod4': (('Hyper_L', 'Hyper_L'), ('Hyper_R', 'Hyper_R')), 'mod5': (('Mode_switch', 'Mode_switch'), ('ISO_Level3_Shift', 'ISO_Level3_Shift')), 'shift': (('Shift_L', 'Shift_L'), ((60, 'Shift_R'), 'Shift_R')), 'lock': (((57, 'Caps_Lock'), 'Caps_Lock'),)}) meta=mod1, control=control, numlock=mod2 2014-05-09 17:21:45,918 set_modifier_mappings(..) swap keys translations={'Meta_R': (59, 'Control_L'), 'Control_L': (55, 'Alt_L'), 'Meta_L': (59, 'Control_L'), 'Control_R': (54, 'Alt_R')}
If I'm reading my output right, I'm seeing the following upon clicking the Command key:
2014-05-09 17:24:41,738 mask_to_names names=['mod2'], meta_on=False, meta_set=False, control_set=False 2014-05-09 17:24:41,738 mask_to_names(<flags GDK_MOD2_MASK | GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2']
Followed by... the following when I try to click on a select list:
2014-05-09 17:25:02,671 mask_to_names swapping meta for control: mod1 for control 2014-05-09 17:25:02,671 mask_to_names(<flags GDK_MOD2_MASK | GDK_META_MASK of type GdkModifierType>)=['mod2', 'control'] 2014-05-09 17:25:02,671 parse_key_event(<gtk.gdk.Event at 0x8c73f08: GDK_KEY_RELEASE keyval=Meta_L>, False)=<GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}> 2014-05-09 17:25:02,671 handle_key_action(GLClientWindow(3 : GLPixmapBacking(3, (941, 688), YUV444P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>) wid=3 2014-05-09 17:25:02,672 swap keys: translating key '<GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>' to (59, 'Control_L') 2014-05-09 17:25:02,672 send_key_action(3, <GTKKeyEvent object, contents: {'modifiers': ['mod2', 'control'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': False, 'keyval': 65511, 'keycode': 59}>)
Doing a xpra info | grep keyboard.state
(from another machine) I get no output (I'll try again once I get my hands on a newer rpm).
Looking through the results of a xpra info | grep keyboard
I find the following possibly interesting bits:
keyboard.keysym.Meta_L=156 keyboard.keysym.Meta_L.55=64 keyboard.keysym.Meta_L.58=101 keyboard.keysym.Meta_R=114 keyboard.keysym.Meta_R.54=113 keyboard.keysym.Meta_R.61=114
Yes, I was abbreviating
Command
...
Don't worry about the abbreviation, my confusion came from the fact that the OSX menu was referring to Option
and not Command
- this is now fixed in r6434. (probably because that's the virtualbox key mapping for it). I just wanted to make absolutely certain that we are talking about and testing the same key.
including a traceback that I didn't notice before
As I said in comment:4 you would have seen a stacktrace in the logs - this is fixed in r6421.
fedora 19 server (r6398) (...) a
xpra info | grep keyboard.state
(from another machine) I get no output
As stated above: r6426 adds details in xpra info about which keys and modifiers are pressed under "keyboard.state
". 6398 < 6426.
As for the actual bug:
meta=mod1, control=control, numlock=mod2
Meta
is the GTK name for Command
on OSX):
'Meta_R' : (59, 'Control_L')
'Control_L' : (55, 'Alt_L')
'Meta_L' : (59, 'Control_L')
'Control_R' : (54, 'Alt_R')
When you press the command key, we see: mask_to_names(<flags GDK_MOD2_MASK | GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2']
looks ok: mod2
means NumLock
is on (was it?). And control
is not set because this is the keypress which will be setting it. So far so good. I think.
Then when you click: mask_to_names swapping meta for control: mod1 for control
is what we expect to see, and the names returned by it look fine: ['mod2', 'control']
(which is NumLock
and Control
).
The problem comes from here I think:
parse_key_event(<gtk.gdk.Event at 0x8c73f08: GDK_KEY_RELEASE keyval=Meta_L>, False)=<GTKKeyEvent object, contents: \ {'modifiers': ['mod2', 'control'], \ 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': False, 'keyval': 65511, 'keycode': 55}>
It looks to me like we get a GDK_KEY_RELEASE
event for the Meta_L
key (which is Command
).
We could swallow it to avoid releasing Control
, but this will only work if the following mouse events do have the Command
modifier still set. And I suspect it won't be set, otherwise the server code should have re-pressed it before the click.
Please post the client and server log samples for the control + click event with -d keyboard,mouse
.
It's probably a good idea to turn NumLock
off so that the only modifier we see is the one we are interested in, will be easier to parse.
Ok, got the logs, but there were some interesting points I should note.
NumLock
off. (I think some of your previous work does allow an external keyboard to set NumLock
to off with an osx xpra session, but when I have tried to get local keyboard mappings I have never found a key on osx which will read as having turned NumLock
off.)
xpra info | grep keyboard.state
, for some reason the output dumped into the log file I was running on the server.
As a result of that second, the server-side log file is conveniently broken up. The output from before the keyboard.state info is mouse and keyboard output from clicking on the window and navigating to a page with a select list. Once I had the Command button clicked I then ran the xpra info | grep keyboard.state
, and immediately below that in the logs are several Command+Clicks.
Hopefully that info will make the logs easier to browse through (I also tried to keep them as short as possible).
client side output, Command + Click, osx 0.13.0 r6434
server-output, Command + Click & keyboard.state
I am using a laptop keyboard that has no key to turn
NumLock
off.
In that case, you should still be able to turn it off via the global menu under Features
-> Num Lock
. No big deal.
Here is the important part, client side (edited):
set_modifier_mappings(...) meta=mod1, control=control, numlock=mod2 handle_key_action(ClientWindow(2), <GTKKeyEvent object, contents: \ {'modifiers': ['mod2'], 'group': 0, 'string': '', \ 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>) wid=2 swap keys: translating key '<GTKKeyEvent object, contents: \ {'modifiers': ['mod2'], 'group': 0, 'string': '', \ 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>' to (59, 'Control_L') send_key_action(2, <GTKKeyEvent object, contents: \ {'modifiers': ['mod2'], 'group': 0, 'string': '', \ 'keyname': 'Control_L', 'pressed': True, 'keyval': 65511, 'keycode': 59}>) _button_action(1, <gtk.gdk.Event at 0x17820c20: GDK_BUTTON_PRESS x=401.00, y=501.00, button=1>, True) \ wid=2, pointer=(401, 545), modifiers=['mod2'], buttons=[] _button_action(1, <gtk.gdk.Event at 0x17820c38: GDK_BUTTON_RELEASE x=401.00, y=501.00, button=1>, False) \ wid=2, pointer=(401, 545), modifiers=['mod2'], buttons=[1]
So the button events do not have any modifiers set apart from mod2
(aka NumLock
), despite the fact that we are seeing a Meta_L
keypress (correctly translated as a Control_L
) prior to the corresponding keyrelease.
What is interesting here is that at the top of the client log file I see that you pressed meta-v and that the modifier was correctly set for that event (and must have resulted in a control-v event server side).
It looks to me like Meta_L
is only missing from mouse events (both motion and clicks).
At that point I quickly ended up here:
xkbmap_mod_pointermissing
:
when called from mouse position/click events we ignore 'xkbmap_mod_pointermissing' which is set by the client to indicate modifiers which are missing from mouse events. ie: on win32, "lock" is missing.
So I had seen a similar bug for "lock
" on win32 before, and added this fairly generic workaround. I am not entirely happy about how we decide if this is a mouse event or keyboard event in make_keymask_match
, it should probably be a flag instead. But this will have to do for now.
The problem is that the xkbmap_mod_pointermissing
list is populated by get_keymap_modifiers
at connection time, but control
is only missing when we have swap keys on... which can change at runtime.
afarr: Were you running with keyboard sync disabled? The key event does this on the server:
handle_key(2,True,Control_L,65511,37,('mod2',)) keyboard_sync=False handle keycode pressing 37: key Control_L fake_key(37, True) handle keycode unpressing 37: key Control_L fake_key(37, False)
Which should only happen if you disable keyboard sync.
Which nicely brings me to the next problem: a xkbmap_mod_pointermissing
based solution will not work when keyboard sync is disabled... unless we ignore modifier keys from the auto-repress codepath, which would not be unreasonable.
work in progress patch so each keyboard implementation can specify which modifiers should be ignored and when
I didn't enable or disable the keyboard sync, so it should have been running with default- which I'd assumed to be enabled.
While re-running test with newer osx for #563, I ran a quick xpra info | grep keyboard
and noticed keyboard.sync=False
. The --help lists show the default --keyboard-sync to be %
, so I suppose there are heuristics that decide which way to set it on connection?
In any case, I tried to re-run the test with an explicit --keyboard-sync
added to the client-side attach command.
I'll attach the output logs, in case they're of use, but poring over the client-side log the important bits seem to be exactly the same:
set_modifier_mappings(...) meta=mod1, control=control, numlock=mod2 2014-05-14 11:59:24,062 handle_key_action(GLClientWindow(2 : GLPixmapBacking(2, (1237, 752), YUV444P)), <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>) wid=2 2014-05-14 11:59:24,062 swap keys: translating key '<GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Meta_L', 'pressed': True, 'keyval': 65511, 'keycode': 55}>' to (59, 'Control_L') 2014-05-14 11:59:24,062 send_key_action(2, <GTKKeyEvent object, contents: {'modifiers': ['mod2'], 'group': 0, 'string': '', 'keyname': 'Control_L', 'pressed': True, 'keyval': 65511, 'keycode': 59}>) 2014-05-14 11:59:24,376 _button_action(1, <gtk.gdk.Event at 0x64b8db8: GDK_BUTTON_PRESS x=411.00, y=522.00, button=1>, True) wid=2, pointer=(411, 567), modifiers=['mod2'], buttons=[] 2014-05-14 11:59:24,561 _button_action(1, <gtk.gdk.Event at 0x64b8ea8: GDK_BUTTON_RELEASE x=411.00, y=522.00, button=1>, False) wid=2, pointer=(411, 567), modifiers=['mod2'], buttons=[1]
And likewise, the server-side seems to have same important bits:
2014-05-14 11:59:12,196 handle_key(2,True,Control_L,65511,37,('mod2',)) keyboard_sync=False 2014-05-14 11:59:12,196 handle keycode pressing 37: key Control_L 2014-05-14 11:59:12,196 fake_key(37, True) 2014-05-14 11:59:12,197 handle keycode unpressing 37: key Control_L 2014-05-14 11:59:12,197 fake_key(37, False)
Should we be looking to see if there's a problem with osx client keyboard sync? (Could that be part of clipboard issue?)
client output with explicit --keyboard-sync on attach command
server-side output with explicit --keyboard-sync on client side connection
The
--help
lists show the default--keyboard-sync
to be%
That was a bug, fixed in r6464 for trunk, r6465 for v0.12x.
the client-side log the important bits seem to be exactly the same
Yes. I just found why.. see below.
Should we be looking to see if there's a problem with osx client keyboard sync?
The keyboard-sync
ends up being disabled because we don't have an API call to query the keyboard repeat rate on OSX, so we cannot tell the server the timing of key repeat events... and so we cannot use keyboard-sync
and we turn it off.
Options for dealing with this:
The last one is clearly the best option, but it is yet more code and I haven't merged the patch above because it was already a bit too intrusive...
(Could that be part of clipboard issue?)
Which clipboard issue and why? Clipboard and keyboard have very little in common. If you mean that newer GTK builds may also fix this issue, I doubt it, but it is definitely worth a try. Do you have one available?
r6472 skips unpressing keys for modifiers, which seems worth doing and does not seem to break anything. As for the patch above, I remain unconvinced it is worth the hassle. Problem is that the only other option would be to close this bug as wontfix
until someone shouts loud enough...
updated patch against latest code
Went for the much simpler option of telling the server not to manage control
for non-keyboard events received from OSX clients in r6515.
afarr: please test to ensure that the control
key does not get out-of-sync with the client, both with --swap-keys
(the default) and --no-swap-keys
. See below for ideas.
The only potential problem that I see is that we may tell the server to press control
when we see it on the client, then the client may unpress it whilst the focus is not on an xpra window and therefore we will not be sending the key release to the server. I believe in this case we should be seeing a focus-out
event, which should end up calling clear_keys_pressed
. But maybe there are other corner cases?
client-side output, 0.13.0 r6521 default swap-keys (short test)
server-side output, 0.13.0 r6521 (short test)
client-side output, 0.13.0 r6521, --no-swap-keys set
server-side output, 0.13.0 r6521, --no-swap-keys set on client
client-side output, 0.13.0 r6521, default swap-keys, with repeated, stationary clicking while Command held (long test)
server-side output, 0.13.0 r6521, with repeated, stationary clicks by client (long)
Ah, sorry about that, it seems that I had missed part of the changeset (fixed in r6522), this showed up in the logs as:
Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/xpra/server/server_base.py", line 1357, in _process_key_action self._handle_key(wid, pressed, keyname, keyval, keycode, modifiers) File "/usr/lib/python2.7/site-packages/xpra/server/server_base.py", line 1395, in _handle_key if not self.keyboard_sync and not self.keyboard_config.is_modifier(keycode): AttributeError: 'KeyboardConfig' object has no attribute 'is_modifier'
Please try again (sorry!) - I assume that things weren't working too well without this...
Using 0.13.0 r6527 OSX client and Fedora 19 server... I'm still finding that the Command key (standing in for Control) doesn't maintain it's "pressed" state if the mouse is moved.
On a probably unrelated note, with the r6527 osx client I am still seeing some warnings, if not actual tracebacks. I'm not sure if they're related to our build, or perhaps something else that missed being committed... or maybe just something related to the quickly aging drivers of this 10.6.8 osx laptop. (I didn't see a recent enough beta of yours to compare with, unfortunately.)
2014-05-22 16:01:41,340 argb module is missing, cannot support alpha channels 2014-05-22 16:01:41,393 cannot import enc_vpx (vpx encoder): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/vpx/encoder.so, 2): Symbol not found: _object_as_buffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/vpx/encoder.so Expected in: dynamic lookup 2014-05-22 16:01:41,395 cannot import dec_vpx (vpx decoder): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/vpx/decoder.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/vpx/decoder.so Expected in: dynamic lookup 2014-05-22 16:01:41,397 cannot import enc_x264 (x264 encoder): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/enc_x264/encoder.so, 2): Symbol not found: _object_as_buffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/enc_x264/encoder.so Expected in: dynamic lookup 2014-05-22 16:01:41,401 cannot import csc_swscale (swscale colorspace conversion): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_swscale/colorspace_converter.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_swscale/colorspace_converter.so Expected in: dynamic lookup 2014-05-22 16:01:41,404 cannot import csc_cython (cython colorspace conversion): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_cython/colorspace_converter.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_cython/colorspace_converter.so Expected in: dynamic lookup 2014-05-22 16:01:41,408 cannot import dec_avcodec2 (avcodec2 decoder): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/dec_avcodec2/decoder.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/dec_avcodec2/decoder.so Expected in: dynamic lookup 2014-05-22 16:01:41,428 cannot import enc_webp (webp encoder): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/webp/encode.so, 2): Symbol not found: _object_as_buffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/webp/encode.so Expected in: dynamic lookup 2014-05-22 16:01:41,431 cannot import dec_webp (webp decoder): dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/webp/decode.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/webp/decode.so Expected in: dynamic lookup 2014-05-22 16:01:42,463 xpra client version 0.13.0 ** Message: pygobject_register_sinkfunc is deprecated (GstObject) 2014-05-22 16:01:42,773 csc module csc_swscale could not be loaded: dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_swscale/colorspace_converter.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_swscale/colorspace_converter.so Expected in: dynamic lookup 2014-05-22 16:01:42,774 csc module csc_cython could not be loaded: dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_cython/colorspace_converter.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/csc_cython/colorspace_converter.so Expected in: dynamic lookup 2014-05-22 16:01:42,774 video decoder dec_avcodec2 could not be loaded: dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/dec_avcodec2/decoder.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/dec_avcodec2/decoder.so Expected in: dynamic lookup 2014-05-22 16:01:42,774 video decoder dec_vpx could not be loaded: dlopen(/Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/vpx/decoder.so, 2): Symbol not found: _memory_as_pybuffer Referenced from: /Users/alex/Desktop/xpra-testings/xpra6527/Xpra.app/Contents/Resources/lib/python/xpra/codecs/vpx/decoder.so Expected in: dynamic lookup
Sounds like any mouse motion event is "losing" the control modifier, can you post the server logs with -d keyboard,mouse,focus
of just around when you move the mouse (when the modifier gets lost).
As for the errors, they show that most encodings have failed to load, you must have ended up with just the default software ones (rgb
, jpeg
and png
only - maybe webp
if your build of Pillow is recent enough), no video, etc. That's a pretty big problem.
Linking with buffers.c
has been present since r6252, odd that we would only start getting errors now!? And I don't think you've seen these errors with my beta builds post r6252?
I've just uploaded a new beta build which I have tested on a clean "Mountain Lion" virtual machine without seeing those problems.
smo: ideas?
Finally figured out a way to test this, using an external USB keyboard and virtualbox's USB pass-through. Works for me as of r6549. So this will be part of the 0.13 release!
Please verify then close this ticket.
Tested with r6587, client & server - looks splendid. Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/567