samhocevar
New compose key behavior affects virtual machines
I'm writing this without much confirmation, if this turns out to be garbage feel free to delete this report.
I have WinCompose running on both my Windows host and inside a VMware VM also with Windows. Up until now I could use my compose key (Menu) on both machines without problems.
Today I've upgraded to v0.7.7 on the host (only). And what happens now is that the compose key is getting hijacked even if I'm in the VM. The keypress is registered on the host but the sequence isn't printed to the VM.
The compose key works perfectly on the host. and if I disable WinCompose on the host it still works perfectly in the VM.
So something might have changed in the way WinCompose is hijacking the key press and it affects virtual machines.
It might be related (a lot of things changed in the way keypresses are handled, hopefully for the better, but there are still a few adjustments to make).
When the compose key used to work in the VM, do you know whether it was the hosts’s WinCompose or the guest’s that was actually doing the work? You can easily tell by creating a custom sequence and seeing whether it works inside the VM.
I can say this:
- I'm using VMware as the hypervisor
- VMware is configured to not use "Enhanced Keyboard" features.
- I have WinCompose v0.7.6 installed on both the host and the VM.
- I have a custom sequence defined on the host.
Scenario 1:
- I'm on the host
- I press
<compose> <custom sequence>
→ The result is the defined custom sequence, the WinCompose tray indicator is lit appropriately
Scenario 2:
- I'm in the VM
- I press
<compose> <custom sequence>
→ The result is not the custom sequence, the WinCompose tray indicator is not lit
Scenario 3:
- I'm on the host
- I press
<compose> - I switch to the VM
- I press the
<custom sequence>
→ The result is not the custom sequence, the tray indicator is only lit appropriately on the host. If I change back to the host I can successfully complete the sequence.
To me this indicates that the keyboard input is isolated properly and the compose key and its sequence are properly interpreted.
I don't have v0.7.7 installed at the moment but there the behavior was different: It seemed the host took priority over the VM. However, the host was also the only one with v0.7.7 installed so the result is a bit inconclusive.
If it helps I might take some time and install v0.7.7 on both machines and test again then.
I just ran into this myself. Inside the Linux VM, Compose+-+> gives me E instead of →. On the host, I get the proper →.
Exiting WinCompose on the host makes the VM's compose key work properly again.
Clearly WinCompose at fault here.
So is this still happening for 0.8.0? Because this bug is blocking me from updating.
Updated to 0.8.0, bug's apparently still present. Downgraded to 0.7.6 (again), and compose works in Linux guest (again).
Update to 0.8.2: still there, but (though this may have been with 0.8.0 already) now the first sequence in the VM after switching to it works, then it stops.
- Switch input focus from host to VM window.
- Enter compose sequence.
- Expected code point is entered in VM.
- Enter compose sequence.
- No code point is entered in VM.
- Switch input back to host, repeat from 1
Downgraded to 0.7.6 again. Tried 0.7.7 but today noticed (when trying a compose sequence in the VM) that that was the first version with this bug. :(
0.9.0 has the problem still, but… now you can enter two compose sequences into the vm correctly, and the third and following give some letter.
COMPOSE+.+. (ellipsis) gives me two ellipses, and then a lower-case l on the third sequence. With 0.8.2 it was one ellipsis and the a lower-case l.
In WinCompose 0.9.11 I solved this using the "Ignore windows matching this regex" option, and using the window title of the VM. For example, something like ^Ubuntu.* or .*VirtualBox$ which prevents WinCompose from listening to keystrokes when a VM window has focus.
