Forum Replies Created
-
Posts
-
Ok, I figured it out. In the VM configuration as accessed via VMWare vSphere Client (vCenter), the default behavior of a VM seems to be to cap the video memory at 4MB, which only allows so much resolution. I had to power down the VM, then use vSphere Client to change the video memory of the VM to support my local monitor resolution (1920×1200), which is just under 8MB according to their calculator widget.
Once I made that change, and booted the VM back up, NoMachine is able to automagically set the remote resolution (using xrandr or whatever) to support fullscreen on my local monitor. In fact, it works better than RDP, which forces me to reconnect to my remote machine to change the resolution as viewed locally.
The speed behind this protocol is really blazingly fast! It was definitely worth the effort to get it going vs X11RDP. But, I wish either the VMWare display driver, or xrandr, or NoMachine surfaced the reason better as to why the resolution wasn’t going any higher. Probably all of those things need to change, which means they won’t. If this phenomenon was documented in a FAQ or forum, then my first experience with NoMachine would have been a lot less painful.
I spent the day today creating a new VM with a more recent Ubuntu version (Kubuntu 15.04-alpha2), and which I haven’t put X11RDP onto (to avoid any conflicts). The result is better. But what looks like is happening, is the X Server is starting up with the “vmware” display driver, and the driver is not adding support for higher than 1366×768 resolution. If I try to manually add any higher resolutions and use xrandr to switch to them, I get nasty and uninformative opcode errors from xrandr. But, I can switch to 1366×768, at least. After giving up on the antique ESX vmware-tools, I installed the open-vm-tools and open-vm-tools-desktop packages with apt-get.