Xpra: Ticket #567: cannot control click to select multiple items in lists on osx

Split from #566

afarr: please confirm and provide details. You should be able to find lists with multiple items selectable using a browser.



Thu, 08 May 2014 13:21:36 GMT - Antoine Martin: owner changed


Thu, 08 May 2014 21:29:56 GMT - alas:

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


Thu, 08 May 2014 22:02:13 GMT - alas:

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?


Fri, 09 May 2014 10:57:15 GMT - Antoine Martin:

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.


Fri, 09 May 2014 23:19:59 GMT - alas:

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

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.


Sat, 10 May 2014 00:45:01 GMT - alas:

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

Sat, 10 May 2014 04:29:05 GMT - Antoine Martin:

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:

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.


Wed, 14 May 2014 00:13:43 GMT - alas:

Ok, got the logs, but there were some interesting points I should note.

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


Wed, 14 May 2014 00:15:20 GMT - alas: attachment set

client side output, Command + Click, osx 0.13.0 r6434


Wed, 14 May 2014 00:25:28 GMT - alas: attachment set

server-output, Command + Click & keyboard.state


Wed, 14 May 2014 03:34:47 GMT - Antoine Martin:

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


Wed, 14 May 2014 04:24:40 GMT - Antoine Martin:

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.


Wed, 14 May 2014 06:17:47 GMT - Antoine Martin: attachment set

work in progress patch so each keyboard implementation can specify which modifiers should be ignored and when


Wed, 14 May 2014 19:18:07 GMT - alas:

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


Wed, 14 May 2014 19:19:08 GMT - alas: attachment set

client output with explicit --keyboard-sync on attach command


Wed, 14 May 2014 19:27:00 GMT - alas: attachment set

server-side output with explicit --keyboard-sync on client side connection


Thu, 15 May 2014 04:33:27 GMT - Antoine Martin:

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?


Thu, 15 May 2014 07:02:48 GMT - Antoine Martin:

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


Thu, 15 May 2014 07:06:06 GMT - Antoine Martin: attachment set

updated patch against latest code


Mon, 19 May 2014 03:13:11 GMT - Antoine Martin:

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?


Mon, 19 May 2014 23:27:05 GMT - alas: attachment set

client-side output, 0.13.0 r6521 default swap-keys (short test)


Mon, 19 May 2014 23:28:09 GMT - alas: attachment set

server-side output, 0.13.0 r6521 (short test)


Mon, 19 May 2014 23:29:11 GMT - alas: attachment set

client-side output, 0.13.0 r6521, --no-swap-keys set


Mon, 19 May 2014 23:30:05 GMT - alas: attachment set

server-side output, 0.13.0 r6521, --no-swap-keys set on client


Mon, 19 May 2014 23:31:28 GMT - alas: attachment set

client-side output, 0.13.0 r6521, default swap-keys, with repeated, stationary clicking while Command held (long test)


Mon, 19 May 2014 23:32:35 GMT - alas: attachment set

server-side output, 0.13.0 r6521, with repeated, stationary clicks by client (long)


Tue, 20 May 2014 05:24:34 GMT - Antoine Martin:

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


Thu, 22 May 2014 23:25:43 GMT - alas:

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

Fri, 23 May 2014 05:50:44 GMT - Antoine Martin:

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?


Sat, 24 May 2014 15:07:42 GMT - Antoine Martin:

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.


Tue, 27 May 2014 23:01:55 GMT - alas: status changed; resolution set

Tested with r6587, client & server - looks splendid. Closing.


Sat, 23 Jan 2021 04:59:35 GMT - migration script:

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