Remote desktop opengl windows 7

The solution I ended up using was to: Disable Remote Desktop. Delete all other software for remote desktop access. Because if it's used for logging in remotely the current set of drivers loaded may be messed up.

Install NoMachine NoMachine is my personal favourite when it does not play up for a number of reasons: Hardware acceleration of compression video of desktop. Works on Windows and Linux. Works well on low-bandwidth connections especially if the client and server have the necessary hardware for compression of the data stream.

On Linux you get your desktop as you last left it when you were sitting in front of the machine. On Windows it does not affect OpenGL. Do check the licence in case it's changed. Damian Dixon Damian Dixon 7 7 silver badges 19 19 bronze badges. The Overflow Blog. Stack Gives Back Safety in numbers: crowdsourcing data on nefarious IP addresses. Featured on Meta.

New post summary designs on greatest hits now, everywhere else eventually. Linked 5. Related Hot Network Questions. FrostKiwi FrostKiwi 1 1 gold badge 5 5 silver badges 12 12 bronze badges. Add a comment. Active Oldest Votes. By running gpedit. Improve this answer. Wai Ha Lee 8, 63 63 gold badges 57 57 silver badges 86 86 bronze badges. WaiHaLee that is totally possible.

Right now I don't own any en-us Windows, and what I wrote was a translation from my native language, backed by some quick googling to double-check the group policy's name. If you do have a en-us or en-gb version of Windows, I'd be grateful if you could check that and update the text with what you see in EN version. The default word there could make a difference there is a notion of "default graphics adapter" in the OS , but I'm pretty sure that I saw none similarly-named policies, so whatever you see there - most probably is the same policy I wrote about — quetzalcoatl.

Okay - thanks for confirming. I've updated the answer with the string as it appears on my en-gb machine - and added the url for a screenshot also from my machine to the edit summary. If you are using an nVidia card you will need to install Nvidia-opengl-rdp may require nvidia account.

Show 8 more comments. Deepstop 3, 2 2 gold badges 6 6 silver badges 19 19 bronze badges. Agreed, this combined with updating RDC settings works. Thank you very much!

Mesa3D for Windows works perfectly which is provided in your last link. This means that OpenGL is actually running on the client computer. Besides, client machines may not support OpenGL 2. So the question is how to force RDP to run OpenGL on host computer in scenario 2 so that it works the same as in scenario 1. Now you want to use OpenGL apps in such a scenario. Both checks are successful in this scenario and both flavors of OpenGL run properly. Now you go to your home PC and establish a remote connection to this user session.

During the connection process, the capabilities of the home PC's graphics card is sent to the host PC in order to optimize the graphics output.

This is required to do some rendering on the receiver side rather than on the sender side. In your "remoting into existing user session" scenario the OpenGL output on the host is sent to the client pixel by pixel. When you establish a new connection from a home PC to an office PC, the home PC's graphics capabilities are relevant for the user session.

Such a remote session does not support OpenGL in hardware - in other words, there is no 3D hardware graphics support. So your system works as designed even if it sounds weird. Note: In both scenarios all applications run on the office PC. In the second scenario the graphics options are a little bit different due to the OpenGL app already launched in the existing user session.

Actually, I'm surprised that it works at all. I would have expected that the hardware OpenGL app throws an error when remoting into the existing session. This option also supports OpenGL in hardware if the appropriate graphics adapter is installed on the Hyper-V server.

The idea was to launch OpenGL application in some automatic way when there is no remote session attached to the office computer so that OpenGL application would start in hardware mode. From my home computer I connected to the office computer and launched the special process that had some delay before running CAD application. The delay was enough to abort remote session before the start of the OpenGL application.

I tried. What was my mistake and are there any other options for this idea? This will not work as you are terminating the active user session you are connected to before launching the OenGL app through the Task Scheduler.

Because of this the OpenGL app will not start in the right user session remember, it's terminated or it will launch in the wrong user session if there is any. At this moment I don't know of any way to accomplish what you want to do without someone sitting in front of the physical console and start the user session and the app for you. Session ID can be found with qwinsta. Then launching the application and then connecting back with remote desktop.

I have read through this admittedly very old thread and it is very close to the problem I am having with just some new problems. I also am trying to avoid any sort of batch file changes like the ones recommended.

Here is my situation:. I am an admin on this server but I am not a server expert. Cura responds with a "Failed to probe OpenGL" error. Any help is greatly appreciated. I am having problems with an aplication that it runs via remote desktop of Microsoft.

The computer have Windows 10 Enterprise like Operating System. My application show a picture in 3D. I used the remote desktop of window, all descriptions happen on the remote.