ctrl modifier not applied in certain situations (vmware horizon client window with Windows guest) about xpra HOT 6 CLOSED

keynames(control)=['Control_L', 'Control_R'], keycodes=[37, 109], nuisance=False, nuisance keys={'lock', 'mod2'}
add control with keycode 37 did not work

The keymap that xpra is working with has Control_L = 37, Control_R = 109 but somehow this is not correct?
Perhaps vmware modified the keymap?

xmodmap doesn't show any bindings

Yes, so something is definitely messed up. It should match the values above.
I'm going to close this as not-an-xpra-bug.

from xpra.

Yeah, lobotomizing the change_mask logic by unconditionally accepting the keycode (by setting modkeycode = keycode and breaking out of the loop, instead of un-pressing it) does get this working. (And thank you, your response was critical!)

If I can figure out a reasonable way to express the particular pathological behavior of this program and handle it gracefully, I'll submit a PR. But I too am pessimistic.

from xpra.

@aerusso how about the commit above?
Run with XPRA_VERIFY_MODIFIERS=0 xpra ...

from xpra.

Thanks! I'm trying to get at a more general solution (but I'm failing). What I was hoping to do was basically this, but contingent on the modmap being empty (rather than checking a switch). After looking at the code, though, it appears that it should already be doing (something very close to) that! I.e., it should bail out of doing any of this careful mask-adjusting logic if the modmap is empty.

So, I investigated further: in _keys_changed in xpra/server/mixins/input.py, the call to ss.keys_changed() is guarded by a keymap_changing_timer. On my system, that is always an integer. And it's only ever zero on the first call to it. (Maybe there's an expectation it's one of the other timer implementations?) So, I think that may be a bug. It consequently is never calling the keymap-changing code (i.e., compute_modifier_map) . Bingo, I though!

Notwithstanding that, I went ahead and removed the if not self.keymap_changing_timer (since I only ever saw that function being called once per layout change, anyway). I also added in a sleep(0.02) to sweep race conditions under the rug for debugging. The keymap is empty (confirmed via xmodmap), but grok_modifier_map was showing up with all the modifier keys in it. So, either there's a race, and I need a longer sleep() there, or GDK is maybe lying to us about the keymap?

With this, I'm unfortunately out of time to look into this right now. And I'm not sure I'm willing to trace into GDK to figure out what exactly is going on there. I'll look into this more later, but it will unfortunately have to wait at least a ~week.

from xpra.

since I only ever saw that function being called once per layout change, anyway

Lucky you!
(this function can fire many times on some platforms..)

The keymap_changing_timer value is used as a guard to prevent running the same do_keys_changed function multiple times in quick succession:

The only slight issue that I can see is that we may miss a change event if it somehow fires whilst we're processing do_keys_changed.
This should not be possible as the events and the timers run in the same thread... but whatever, I've changed the order in 375c8f4

from xpra.

@aerusso how about the commit above? Run with XPRA_VERIFY_MODIFIERS=0 xpra ...

I just tested this. Indeed, these two commits do fix the issue (I had to backporting 374175e to 5.0).

(I still want to see if I can figure out a more general solution, but it will obviously take some time.)

from xpra.