Cura: [4.1.0] Opengl failure stopping application launch when it doesn't need to (rdp)

[MrStonedOne]

Application version
4.1

Platform
windows 7

Printer
n/a (this bug happens before printer can be setup)

Reproduction steps
Start cura while in remote desktop

Actual results
opengl not found prompt

Expected results
it works

Additional information
Cura will complain about not finding opengl and not start when ran while remote desktop'ed in.

HOWEVER. Starting cura from the computer directly then connecting to RDP works and everything displays correctly, meaning that the failure does not need to occur and the prompt should be bypassable.

Also this template, like all bug templates is garbage and reduces readability. Here is the same bug report without a template:

---

On windows if you attempt to start cura while in remote desktop it fails to start saying it can't probe opengl, how ever it works fine over remote desktop if you start it up from the console session (ie, directly from the computer) then connect over remote desktop, shapes display fine and everything, suggesting it is failing to start in a situation where it can actually start.

I'm running windows 7.

---

You see how much easier to read that is?

[rburema]

This seems to be a limitation of Windows RDP:
https://stackoverflow.com/questions/51705471/current-state-and-solutions-for-opengl-over-windows-remote

[rburema]

Also: Re: The template: We sometimes get reports that are just a title, like "does not work". Occasionally, that may be an actual bug report we really want to be aware of. The template is to save us some work asking relevant information every. single. time.

(Also it's quite easy to read if you know the format and/or are looking for a specific bit of information, like OS.)

[Ghostkeeper]

Since we use shader objects to render layer view, I don't think that layer view would work under RDP.

[Clint67]

I agree with MrStonedOne.
If it works locally and it is still working under RDP -after- the app has been launched on the 'real' desktop it means the problem is easely bypassable if programmers want to.
In my opinion, it could be related to an old RDP project as to the 'warming planet' but it remains not clear why a 'command line option' or configuration option to bypass the 'starting test' on OpenGL seems to be not available.

[LipuFei]

There is a more extensive analysis on this problem from microsoft forum: https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS

EDIT 1: This thread discusses Windows 7.

I quote the following from that thread:

>

In essence, you are using RDP to remote into a physical desktop PC. So host (office PC) and client (home PC) are both workstation OSes. Now you want to use OpenGL apps in such a scenario.

When you start the OpenGL apps on the office PC using the physically attached monitor and keyboard, the graphics card may be checked by OpenGL - there are some OpenGL apps that require physical hardware support and other OenGL apps that are happy with rendering OpenGL in software. 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. This is done for GDI graphics primitives, but not for openGL primitives. 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. This is why only the software OpenGL app starts, but not the hardware OpenGL app. 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.

I'm afraid that there's not much can do about this behaviour if you don't want to invest into Citrix (HDX Pro) or VMware/Teradici (PCoIP in HW) which supports 3D graphics acceleration in hardware from workstation to workstation. Another option is to run your OpenGL apps in Win7 virtual desktops hosted on Windows Server 2008 R2 SP1 Hyper-V and use the RemoteFX extension of the RDP protocol. This option also supports OpenGL in hardware if the appropriate graphics adapter is installed on the Hyper-V server.

Benny

I just tested on a Windows Server 2019 VM with NVIDIA graphics card. I started a RDP session, only installed the NVIDIA driver and Cura 4.2.1 on it, and then I started Cura. This works for me. According to that information, the graphics card capability on your local/client computer also matters. My local/client computer has the following hardware configuration. I can also start Cura 4.2.1 on my local/client computer.

• OS: Windows 10 Pro x64 Version 1809 (OS build 17763)
• CPU: Intel Core i7-7500U
• RAM: 16GB
• GPU:
  
  
  
  • Intel HD Graphics 620
  
  
  • NVIDIA Quadro M520
  
  

I don't have a computer that cannot run Cura at the moment. But if what's mentioned in that thread is correct, I think you can first try to run Cura 4.2.1 on your local/client computer see if it starts. If so, at least we know that your RDP client has the graphics hardware capability to run Cura, and thus running it via RDP should work as well.

[fieldOfView]

Here's a workaround, in the form of a BAT script that closes the remote desktop connection and starts Cura. It is then up to the user to restart the remote desktop connection.

@echo off
echo Remote Desktop will be temporarily disconnected. Please reconnect after a few seconds.
pause
@echo on

REM The active session has an arrow as the first character
setlocal EnableDelayedExpansion
FOR /F %%A in ('qwinsta') do (
    set tempSessionName=%%A
    if "!tempSessionName:~0,1!"==">"  ( 
        @echo on
        tscon.exe !tempSessionName:~1! /v /dest:console 
        @echo off
    )   
)
@echo off
echo Starting Cura . . .
call "C:\Program Files\Cura 4.4\Cura.exe"
pause

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.