Workstation Pro 15.1.0 Issue - ALT Key Functions Outside of Guest Instead of Inside Guest

[LongTimeUser]

This has been brought up several times before...

https://communities.vmware.com/thread/606608

https://communities.vmware.com/thread/602468

To name a couple. It was mentioned that the next release of Workstation 15 Pro would resolve. The latest release is 15.1.0 build-13591040 (released on 05/14/2019), which is what I have installed. I have 3 Guests... 1) Windows 10 LTSB, 2) Windows 10 Pro, 3) Windows 7 Ultimate. They all have the same behavior. I've made several attempts at changing VMware Host settings to no avail. I ran Workstation Pro 12 up to this point with no related issues.

When working in Guest, I commonly use keyboard shortcuts. I use ALT-F4 to close Windows almost exclusively. Why waste time trying to click on the X when a simple key press will work? Well, this results in VMware Workstation completely shutting down. Typically without warning. Sometimes (and I'm not sure what warrants the change) it will warn me that Guests are still running. I have not changed the settings for this except for testing... the inconsistent behavior is consistent across settings.

Another annoying side effect of this glitch is that an ALT-TAB, which I use nearly as much as ALT-F4, puts the ALT key in "phantom pressed mode" for the Guest. I have to press ALT in the Guest before I accidently hit some other key that results in an undesired ALT-key function.

Thanks.

EDIT: Okay, 24 hours later, 77 views, and no responses at all, I'll assume this is a known issue with no resolution. I'll downgrade to Pro 14 and see if the issue is resolved.

[wila]

Hi,

Sounds to me that on switching between VMs the keyboard shortcut is going to the VMware Workstation application instead of the VM in it.

You might want to try the following tweak:

Putting a checkbox in the "Grab keyboard and Mouse input on keypress"

In theory at least that should prevent your issue from happening.

PS: 77 views is nothing and you can't assume anything from that, it might even just have been mostly bots "viewing" your post.

--

Wil

[LongTimeUser]

Thanks for the suggestion wila.

Your suggestion was the first thing I tried (with no luck) as it is the most applicable setting that could cause this behavior. It behaves the same way regardless of that setting.

I am running Workstation Pro 15 on a Redhat 8.0 Host and the Guests indicated above.

[LongTimeUser]

So this is a known issue as reported by many users, VMware states they have/will fix it and it's still not resolved.

I really expected more from the VMware team.

[sjesse]

Its may be just a Linux related issue, I've been working in the latest version of 15(just installed it on a new system), and I can't replicate this.

[LongTimeUser]

Fair enough. Some background on my desktop environment.

My previous Host was CentOS 7 and Workstation 12 Pro. Everything worked fine except multiple monitor support.

My current Host is Redhat 8 (GNOME) and Workstation 15 Pro. Everything seems to work fine except ALT key usage.

If I may ask, what Host OS are you using for your 15 Pro instance? What Host settings do you suspect could play a role?

[sjesse]

Windows 10, I tried CentOS and Ubuntu awhile ago but ran into many issues like you are seeing. Its the first released red hat 8.0 is supported, so as you mentioned its probably a bug, so if its possible I'd try 7.5.

[hzuo]

In both topics you have referred, the shortcut key of the menu didn't work in the Workstation Pro on Windows OS.

The issue is fixed in the latest version.

I think it is different from your issue because your Workstation is on Linux

If I understand correctly, your issue is that after you press the "Alt+F4" to close the window in the guest, the Workstation quits.

In the previous reply, I know your host is Redhat 8 (GNOME).

Would you please tell me what is your guest?

Is the guest OS consistent with before?

[ConfusedOnLinux]

Which version of Workstation contains the fix?

My freshly installed version 15.5.1, also running on a Linux host with Linux guests, has exactly the same problem.

[ConfusedOnLinux]

I also reproduced the bug on a fresh Debian install using the latest version of Workstation.

However, disabling Wayland and reverting to X11 appears to solve the problem.

[ilp1968]

Any news on this issue? I'm experiencing the same behaviour running VmWare Workstation Pro 16.1.2 build-17966106 on RHEL 8.4 (Gnome 3.32.2) with a Win10 Guest.

ALT+Tab tabs out of VmWare Workstation. And once back inside I have to unstick the Alt key lest I inadvertedly use menu shortcuts. Luckily I never took up the habit of using ALT+F4...

@ConfusedOnLinux, you mentionned reverting from Wayland to X11 - can this be accomplished easily on RHEL 8? What are the downsides? Would X11 be able to serve high-dpi monitors?

Thanks

EDIT: interpunction...

EDIT2: Thanks @ConfusedOnLinux  - just switched the session at login.

[ConfusedOnLinux]

Hope that helped! You should be able to switch it permanently in the config - for me it's setting "WaylandEnable=False" in the Gnome settings under /etc/gdm/custom.config

I'm afraid I don't know anything else about the "side effects" this might have. Hoping that this gets patched properly at some point.

[ilp1968]

Thank you for the reply, @ConfusedOnLinux .

I found some time to think it over.

My understanding is that this is more related to the way Wayland handles the keyboard, and not VMWare Workstation specific. We can safely rule out Gnome, as switching the renderer engine with the same version of Gnome and VMWare Workstation changes the behaviour. And for the same reason we can rule out VMWare Workstation. So I don't expect this to be fixed in a future Workstation release.

The theoretical downsides of X11 are quite simple: Security. Every app can see what you see on the display under X11, there is no way to hide information from other clients with X11. That was one of the main drivers for developing Wayland if I recall correctly.

This behaviour of Wayland could be a security feature: it prevents a malicious app to even know that another app window has focus. I can't appreciate the pros/cons of this yet; I'll have a look at the wayland docs if time permits.

As for practical downsides I found none either. It just works. But I switched back to wayland after observing the system took almost a minute to shut down whereas with Wayland it powers off almost immediately.