Recent versions of vmtools use KMS, or at least tries when it loads the plugins:
tc@box:~$ find /usr/local/lib/open-vm-tools/plugins
/usr/local/lib/open-vm-tools/plugins
/usr/local/lib/open-vm-tools/plugins/vmusr
/usr/local/lib/open-vm-tools/plugins/vmusr/libresolutionSet.so
/usr/local/lib/open-vm-tools/plugins/vmusr/libdndcp.so
/usr/local/lib/open-vm-tools/plugins/vmusr/libdesktopEvents.so
/usr/local/lib/open-vm-tools/plugins/vmsvc
/usr/local/lib/open-vm-tools/plugins/vmsvc/libvmbackup.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libtimeSync.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libresolutionKMS.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libpowerOps.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libguestInfo.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libgrabbitmqProxy.so
/usr/local/lib/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
/usr/local/lib/open-vm-tools/plugins/common
/usr/local/lib/open-vm-tools/plugins/common/libvix.so
/usr/local/lib/open-vm-tools/plugins/common/libhgfsServer.so
open-vm-tools-10.2.5/services/plugins/resolutionSet/resolutionCommon.c looks for Xorg vmware driver version info:
g_debug("%s: Scanning for VMWare Xorg drivers.\n", __func__);
for(i = 0; i < numPaths; ++i) {
g_debug("%s: Looking for \"%s\".\n", __func__, paths[i]);
driver = fopen(paths[i], "r");
if (driver)
break;
}
if (!driver) {
g_debug("%s: No driver found.\n", __func__);
return -1;
}
g_debug("%s: Driver found. Looking for version info.\n", __func__);
curMatch = versionString;
while (*curMatch) {
if (feof(driver))
goto outNotFound;
curFileChar = fgetc(driver);
if (curFileChar == *curMatch) {
curMatch++;
continue;
} else if (curMatch != versionString) {
curMatch = versionString;
(void) ungetc(curFileChar, driver);
}
}
if (fscanf(driver, "%d.%d.%d", major, minor, level) != 3)
goto outNotFound;
fclose(driver);
g_debug("%s: Version info found: %d.%d.%d\n", __func__, *major, *minor,
*level);
return 0;
outNotFound:
fclose(driver);
g_debug("%s: No version info found.\n", __func__);
return -1;
But I get this in /var/log/vmusr.tc.log. Would stripping cause this? Is there an unstripped version of vmware_drv.so I could try?
[Jul 09 12:44:24.450] [ debug] [resolutionCommon] resolutionXorgDriverVersion: Scanning for VMWare Xorg drivers.
[Jul 09 12:44:24.450] [ debug] [resolutionCommon] resolutionXorgDriverVersion: Looking for "/usr/local/lib/xorg/modules/drivers/vmware_drv.so".
[Jul 09 12:44:24.450] [ debug] [resolutionCommon] resolutionXorgDriverVersion: Driver found. Looking for version info.
[Jul 09 12:44:24.451] [ debug] [resolutionCommon] resolutionXorgDriverVersion: No version info found.
[Jul 09 12:44:24.451] [ debug] [resolutionCommon] resolutionCheckForKMS: ResolutionKMS disabled. (No configuration).
In any event I didn't see any other error message related info in Xorg.0.log. What I posted before is all there was. I did find this at the end of /var/log/vmusr.tc.log:
[Jul 09 12:25:25.061] [ debug] [vmusr] RpcIn: received 23 bytes, content:"Resolution_Set 1918 931"
[Jul 09 12:25:25.061] [ debug] [resolutionSet] Setting guest resolution to: 1176x885 (requested: 1918, 931)
[Jul 09 12:25:25.305] [ debug] [resolutionSet] XRRSetScreenConfig returned 0 (result: 1176x885)
[Jul 09 12:25:25.309] [ debug] [vmusr] RpcIn: sending 23 bytes
[Jul 09 12:25:28.532] [ debug] [desktopEvents] DEXIOErrorHandler
[Jul 09 12:25:28.532] [ message] [desktopEvents] Emitting tcs_de_xioerror due to X I/O error.
When it fails I see this in /var/log/Xorg.0.log:
[ 21.903] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[ 21.903] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 21.903] (II) VESA: driver for VESA chipsets: vesa
[ 21.903] (--) using VT number 2
[ 21.905] (WW) Falling back to old probe method for modesetting
[ 21.905] (EE) open /dev/dri/card0: No such file or directory
[ 21.905] (II) vmware(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 23.513] (EE) vmware(0): Failed to open drm.
[ 23.513] (WW) vmware(0): Disabling 3D support.
[ 23.513] (WW) vmware(0): Disabling Render Acceleration.
[ 23.513] (WW) vmware(0): Disabling RandR12+ support.
As opposed to when it works it looks like this:
[ 46.937] (II) vmware: driver for VMware SVGA: vmware0405, vmware0710
[ 46.937] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 46.937] (II) VESA: driver for VESA chipsets: vesa
[ 46.938] (--) using VT number 2
[ 46.941] (WW) Falling back to old probe method for modesetting
[ 46.941] (II) vmware(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 46.941] (--) vmware(0): DRM driver version is 2.14.0
[ 46.941] (==) vmware(0): Depth 24, (--) framebuffer bpp 32
[ 46.941] (==) vmware(0): RGB weight 888
[ 46.941] (==) vmware(0): Default visual is TrueColor
[ 46.941] (--) vmware(0): Min width 1, Max Width 8192.
[ 46.941] (--) vmware(0): Min height 1, Max Height 8192.
So we probably need to wait for udev? Is there a right way to do this, or do we just loop and sleep and wait for /dev/dri/card0 to exist or eventually give up?