+140
Under Review

Virtual Screen driver similar to that used by MSTSC to eliminate screen resolution limits

Paul 4 years ago updated by Stefan 2 weeks ago 20

Older graphics cards restrict screen resolution. This is not a problem with the Microsoft Terminal Services client which uses a virtual driver and can display much higher resolutions.

Available in Version:
+2

As more and more computers are coming out without a VGA port and only have Display Ports or HDMI ports, this is becoming a fairly big issue and really needs to be addressed as these computers cannot be run headless. Using RDP to access them defeats the whole purpose of ScreenConnect and the additional functionality ScreenConnect provides over RDP.

This also would resolve issues with specific display drivers re: Matrox.

Please, for the love of god do this. It's always disappointing to have these issues and think back to how good life was when I was using LogMeIn with its mirror driver.

Yes. Please. it is terrible to watch the screen move at turtle pace, one keystroke at a time. Please revert to mirror drivers instead of Direct to Video card . Only option is switch to basic VGA mode on server. What is the point in that. LOGMEIN, TEAMVIEWER, no problems. CONNECTWISE could lose clients if they do not move to this feature asap

+1

This is a very big issue for us as well. We manage a lot of servers and the physical ones are almost unusable due to the lag. We are finding ourselves ScreenConnecting into another server and then RDPing into the one we have to work on so it is usable. The guys also complain about the Screensize and why we can't do fullscreen like they can in RDP.

+1

This also does not work to access the console with on Windows Server instances in Google Compute Engine. Major problem; please prioritize fixing. If I RDP in and then join and switch to that session, it works, but there's no independent/external method of getting onto the server unless there's an already-joined RDP session, so that makes ScreenConnect/CW Control utterly worthless to use on a GCE Windows Server instance. :(

Yes, this is an aspect we get complaints on - as most users are remoting in on laptops with much smaller screens.  It requires constantly zooming in and out.  Please develop this asap!

+3

As well as being able to run dual monitor on a remote system that has one monitor

Hey guys,

Are any of your free to jump on a call to discuss this request in more detail? If you are, please use the link below to schedule a time that works for you.

https://calendly.com/cwcontrol_pm/connectwise-control


Thanks!

+5

It seems the resolution issue is increasing on new Windows 2016 and Windows 10 headless nodes. Really hard to work on 640x480 screen.

We also have this issue with connecting to AWS Instance's.  With RDP we can easily connect to a remote server with no physical monitor and tell MSTSC to virtualize across all three 2k Displays at a techs workstation but with ScreenConnect (Control) we have no way of doing this....  

WE simply can not use this product if the laptop lid is closed.

I second this - in addition to the resolution I'm told the mirror driver is much faster as well, similar to TV or RDP. Slow connections are painful currently.

Yes, please develop this. A real pain to jump through 2 hoops to get useful resolution, instead of 1. This should have fixed as soon as it was spotted.

We just signed up for the service and paid for a full year of service, now I am wondering what kind of huge mistake that I just made.  We have many servers in a rack headless at a data center, this is a disaster.  Please fix it.

Had Control for a day and I this is a big issue for us...

Are we any closer to this?  I want to provide remote login via "control" and I have to set up real displays on those remote devices.  Especially if I want more than 1 display.  Why not just let me create a virtual display for screenconnect?

Adding my voice to this. It's understood that this is a remote support tool and thus the flexibility to remotely support nearly anything is a must. 

That said, we have only seen this be a problem with discrete GPU's with Displayport right now. Most of the machines we support are onboard DP and do not have this problem. 

Can't we just send a trigger to the OS / GPU to activate output?  There must be a better solution than RDP or dummy plugs.....

+1

For a tool that is supposed to provide remote access, it is crazy that the function doesn't even work properly all because a laptop might be closed.