Workstation Pro 15 blocks timed screen lock on Ubuntu 18.04 host

[embsysdev]

Problem:

With host configured to go to lock screen after 15 minutes, if WS is running, system remains running at full power with display on. When mouse or keyboard is touched,  the host immediately goes to black screen, and then the password prompt screen appears.  System exhibits similar behavior for suspend on timeout - i.e. if WS is running, system does not suspend.

When WS is not running, the system operates 100% as expected, no issues with timed lock, wake on kbd/mouse, or timed suspend and resume.

To avoid losing data in the VM session, I have gotten into the habit of suspending all VMs and exiting WS before closing the laptop lid or leaving the computer for any length of time.

Host:

Dell G3 3779 laptop w 32GB RAM, running Ubuntu 18.04.2 LTS (4.18.0-22-generic kernel), recently clean installed from official distribution .iso.

Nvidia GeForce GTX 1050 Ti, driver 430.26, prime-select set to nvidia mode. (recommended by and installed with ubuntu-drivers)

tlp-sensible (ubuntu-drivers)

Intel CPU power manager gnome extension (can repro with or without)

VMware Workstation Pro 15.1.0 build-13591040

Guests:

Tested and reproduced on Ubuntu 18.04, Xubuntu 18.04, Ubuntu 16.04.

Conditions:

WS running a single VM windowed or fullscreen on external HDMI display or on built-in LCD.

Network NAT or bridged.

Shared folders on or off.

I had used VMware Fusion on a 2012 Macbook Pro 15 *daily* for the past 7 years, for professional full-time software development using a wide variety of Windows and Linux guests. Fusion on the MBP was an extremely stable and performant combination; damn near flawless.  Alas, Apple doesn't make them like they used to, so when I got the Dell, I coughed up the $240 for WS pro, thinking it would be a similar experience, but with more memory and horsepower.  I hope I wasn't wrong, but at this point I'm not so sure. There are issues with high CPU as well, but I didn't want to get into that on this post

Message was edited by: embsysdev 20:46 MDT GMT-0600

[bonnie201110141]

I can reproduce the issue and have filed an internal bug to track it. Thanks for reporting the issue!

[bonnie201110141 · Accepted solution]

This issue only occurs if the mouse if grabbed in guest OS. From technical perspective, there is no generic solution to this problem. But we can add below option in /etc/vmware/config:

mks.screenSaverTimeout = "..."  # Set to to the number of seconds slightly lower than the host lock setting

Then after the specified number of seconds of idle time in guest, the mouse will automatically ungrab from guest, and the host can lock successfully.

---------------------------------------------------------------------------------------------------------

Was it helpful? Let us know by completing this short survey here.

[embsysdev]

Thanks, I'll give that a try.

The "no generic solution" claim seems pretty dubious.I have not encountered any other Linux desktop applications that exhibit the problem, nor did the problem manifest with any guests under VMware Fusion (yes, I realize that is an entirely different platform).  So it seems clear that the vmware host application is the problem,   Doesn't vmware tools provide a way for the host to monitor the state of the guest and vice-versa? PowerOps, GuestInfo, GTK Toolbox,  etc?

[bonnie201110141]

Here is the elaboration:

This is an issue with how mouse and keyboard grabs were designed in X. The MKS (i.e. the virtual machine thread to interact with mouse/keyboard/screen) grabs the mouse and keyboard, and it appears as though this screen lock application is also trying to do it. Unfortunately X provides no feedback to the MKS that another application is requesting a grab so there is no generic solution to this problem.

And in this thread, some users also mentioned the issue with other virtualization software.

1369880 – Unable to Lock: lock was blocked by an application

So the issue is Linux host specific.

We have a KB with the workaround, but it is too old. We are working on an update.

Thanks for reporting the issue.

[embsysdev]

Interesting, thank you for the elaboration.  

Happy to report that the workaround you suggested is working.  I set it for 10 seconds less than screen timeout.

workstation.product.version = "15.1.0"

# Set the following (seconds) to slightly lower than the host screen lock timeout.

# This is a workaround for the problem of host timed screen lock blocked by vmware

# workstation 15, Suggested by bonnie201110141 on vmware communities July 11 2019.

# 15m = 900s

mks.screenSaverTimeout = "890"