cannot control click to select multiple items in lists on osx

[totaam]

Issue migrated from trac ticket # 567

component: platforms | priority: major | resolution: fixed | keywords: osx

2014-05-08 14:20:43: totaam created the issue

---

Split from #566

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

[totaam]

2014-05-08 14:21:36: totaam changed owner from antoine to afarr

[totaam]

2014-05-08 22:29:57: afarr commented

---

Confirmed. Running osx client 0.12.5 6328 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:

• On initial focus on page with select list, pressing cmd:

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

• With each mouse click, while cmd button is depressed:

2014-05-08 14:02:58,609 mask_to_names(<flags GDK_MOD2_MASK | GDK_BUTTON1_MASK of type GdkModifierType>)=['mod2']

• And, with release of the cmd button:

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

• Server side I see no output until release of cmd button:

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

[totaam]

2014-05-08 23:02:13: afarr commented

---

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?

[totaam]

2014-05-09 11:57:15: totaam commented

---

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

[[BR]]

Next, as per #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.

[totaam]

2014-05-10 00:19:59: afarr commented

---

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

• Out of curiosity, after you mentioned it's supposed to be the 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.

[totaam]

2014-05-10 01:45:01: afarr commented

---

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

[totaam]

2014-05-10 05:29:06: totaam commented

---

Yes, I was abbreviating Command...
[[BR]]
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.
[[BR]]

including a traceback that I didn't notice before
[[BR]]
As I said in comment:4 you would have seen a stacktrace in the logs - this is fixed in r6421.
[[BR]]

fedora 19 server (r6398) (...) a xpra info | grep keyboard.state (from another machine) I get no output
[[BR]]
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:

• the modifiers are mapped as: meta=mod1, control=control, numlock=mod2
• and we use this translation map (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.

[totaam]

2014-05-14 01:13:43: afarr commented

---

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

• I am using a laptop keyboard that has no key to turn 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.)

• When I connected with a second machine to run an 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.

• First click - Command button was already pressed.

• Second click - Command button remained continually pressed.
• Command button then released, mouse to a new selection, Command clicked anew, and mouse (technically trackpad) clicked.

Hopefully that info will make the logs easier to browse through (I also tried to keep them as short as possible).

[totaam]

2014-05-14 01:15:21: afarr uploaded file ticket567-keyboard-mouse_client-output2.txt (122.3 KiB)

client side output, Command + Click, osx 0.13.0 r6434

[totaam]

2014-05-14 01:25:29: afarr uploaded file ticket567-keyboard-mouse_server-output2.txt.txt (339.4 KiB)

server-output, Command + Click & keyboard.state

[totaam]

2014-05-14 04:34:47: totaam commented

---

I am using a laptop keyboard that has no key to turn NumLock off.
[[BR]]
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).

[totaam]

2014-05-14 05:24:40: totaam commented

---

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.

[totaam]

2014-05-14 07:17:47: totaam uploaded file modifiers-ignore.patch (21.8 KiB)

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

[totaam]

2014-05-14 20:18:07: afarr commented

---

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

[totaam]

2014-05-14 20:19:08: afarr uploaded file ticket567_client-output3.txt (105.8 KiB)

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

[totaam]

2014-05-14 20:27:00: afarr uploaded file ticket567_server-output3.txt (355.9 KiB)

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

[totaam]

2014-05-15 05:33:27: totaam commented

---

The --help lists show the default --keyboard-sync to be %
[[BR]]
That was a bug, fixed in r6464 for trunk, 6465 for v0.12x.
[[BR]]

the client-side log the important bits seem to be exactly the same
[[BR]]
Yes. I just found why.. see below.

[[BR]]

Should we be looking to see if there's a problem with osx client keyboard sync?
[[BR]]
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.
[[BR]]
Options for dealing with this:

• find an API call if one exists (just because I couldn't find one previously doesn't mean it doesn't exist)
• make up some values and hope for the best (yuk)
• don't bother unpressing keys immediately if they are modifier keys (since we should be able to keep those in sync anyway through other packets: mouse, focus and key events have them).
  [[BR]]
  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...

[[BR]]

(Could that be part of clipboard issue?)
[[BR]]
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?

[totaam]

2014-05-15 08:02:48: totaam commented

---

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

[totaam]

2014-05-15 08:06:07: totaam uploaded file modifiers-ignore-v3.patch (22.5 KiB)

updated patch against latest code

[totaam]

2014-05-19 04:13:11: totaam commented

---

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?

[totaam]

2014-05-20 00:27:05: afarr uploaded file ticket567_client-output5.txt (94.4 KiB)

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

[totaam]

2014-05-20 00:28:09: afarr uploaded file ticket567_server-output5.txt.txt (291.1 KiB)

server-side output, 0.13.0 r6521 (short test)

[totaam]

2014-05-20 00:29:12: afarr uploaded file ticket567_client-output6.txt (118.7 KiB)

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

[totaam]

2014-05-20 00:30:06: afarr uploaded file ticket567_server-output6.txt.txt (307.6 KiB)

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

[totaam]

2014-05-20 00:31:29: afarr uploaded file ticket567_client-output7.txt (178.6 KiB)

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

[totaam]

2014-05-20 00:32:35: afarr uploaded file ticket567_server-output7.txt.txt (315.5 KiB)

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

[totaam]

2014-05-20 06:24:34: totaam commented

---

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

[totaam]

2014-05-23 00:25:43: afarr commented

---

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.

• Pressing the Command key before each mouse click - works as expected.

• Pressing and holding the Command key while repeatedly clicking the mouse, without moving it - works as expected.
• Pressing and holding the Command key just prior to first click, moving the mouse while holding key pressed, between multiple items of a select list - works as expected with the first click, behaves as if the Command key were not pressed on all succeeding clicks.
• Pressing and holding the Command key prior to moving mouse to first item to click on select list - behaves as if Command key were not pressed at all.

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

[totaam]

2014-05-23 06:50:45: totaam commented

---

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?

[totaam]

2014-05-24 16:07:43: totaam commented

---

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.

[totaam]

2014-05-28 00:01:55: afarr changed status from new to closed

[totaam]

2014-05-28 00:01:55: afarr changed resolution from ** to fixed

[totaam]

2014-05-28 00:01:55: afarr commented

---

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