Hi,
We bought some Teradici cloud access plus licenses to try and get some use out of our on-prem Flames while our Flame artists continue to work remote. I installed and licensed the Teradici linux graphics agent, and I am able to use the pcoip client software to log into the machine.
However, now I can’t get Flame to run in this environment. My guess is that Flame needs to be reconfigured to be able to use the the virtual display and GPU in this environment.
The machine I am testing this out on is:
Centos 7.6
DKU 16.2.0
Flame 2022.1
It previously had HP RGS running on it, which I uninstalled (but this could be causing problems?)
I installed and licensed the pcoip-agent.
Added pcoip.desktop_session=kde-plasma to the /etc/pcoip-agent.conf so the Teradici session would open in KDE.
Ran echo $DISPLAY and the result was :100
Then I added DISPLAY=:100 to /opt/Autodesk/cfg/env.cfg
When I try to launch Flame, here is where it crashes in the shell log:
Jan 10 11:50:05 : Executing command: /bin/sh /usr/bin/xmodmap -display :100 -e "keycode 64 = Alt_L Alt_L Alt_L Alt_L"
Jan 10 11:50:05 : Failed to query list of displays assigned to X screen 0.Failed to query current metamode of screen 0.Failed to add metamodes to screen 0.MENU : /opt/Autodesk/flame_2022.1/menu/default.menu
Jan 10 11:50:08 : GRAPHICS: Visual depth detected as: 8-bit
Jan 10 11:50:08 : Warning: Unrecognized OpenGL version
Jan 10 11:50:08 : Warning: Unrecognized OpenGL version
Jan 10 11:50:08 : Automatic GPU detection failed
Jan 10 11:50:08 : Registered thread 'Res Mgr' [ 140080912951040 ]
Jan 10 11:50:08 : Warning: Unrecognized OpenGL version
Jan 10 11:50:08 : Warning: Unrecognized OpenGL version
Jan 10 11:50:08 : Automatic GPU detection failed
Jan 10 11:50:08 : terminate called after throwing an instance of 'std::logic_error'
Jan 10 11:50:08 : what(): basic_string::_S_construct NULL not valid
Any ideas on how to make it happy? I was thinking wiping it and installing Centos 8.2, but I think I’ll hit the same roadblock.
My experience is that having a DISPLAY= in /opt/Autodesk/cfg/env.cfg causes more problems than it solves, especially when you need to switch the system between local access and Teradici / remote access. So best to leave it empty.
Have you tried removing any trace of DISPLAY in env.cfg? That should typically do the trick.
Also make sure to carefully follow the instructions for configuring /etc/X11/xorg.conf.d/10-pcoip.conf at:
Ah, ok. I’ve removed DISPLAY from /opt/Autodesk/cfg.env.
And I believe the version of Teradici Graphics Agent I installed did not have instructions for creating a 10-pcoip.conf file.
However, I just tried following those instructions to make the 10-pcoip.conf file, rebooted, and I am still getting the same crash.
The shell log references the :100 display even though that is no longer in the .env file, so possibly it is auto-detecting it?
If it should be working now, I might go ahead and wipe it and start fresh. It did have HP RGS installed in the past, and I feel like that could be complicating things.
Here’s the current crash:
Jan 12 14:09:54 : AUDIO : PulseAudio
Jan 12 14:09:54 : Executing command: /bin/sh /bin/xset -display ":100" -dpms
Jan 12 14:09:54 : server does not have extension for -dpms option
Jan 12 14:09:54 : Executing command: /bin/sh /usr/bin/setxkbmap -display ":100" -option srvrkeys:none
Jan 12 14:09:54 : Executing command: /bin/sh /usr/bin/xmodmap -display :100 -e "keycode 64 = Alt_L Alt_L Alt_L Alt_L"
Jan 12 14:09:54 : Failed to query list of displays assigned to X screen 0.Failed to query current metamode of screen 0.Failed to add metamodes to screen 0.MENU : /opt/Autodesk/flare_2022.1/menu/default.menu
Jan 12 14:09:56 : GRAPHICS: Visual depth detected as: 8-bit
Jan 12 14:09:56 : Warning: Unrecognized OpenGL version
Jan 12 14:09:56 : Warning: Unrecognized OpenGL version
Jan 12 14:09:56 : Automatic GPU detection failed
Jan 12 14:09:56 : Registered thread 'Res Mgr' [ 139626397812480 ]
Jan 12 14:09:56 : Warning: Unrecognized OpenGL version
Jan 12 14:09:56 : Warning: Unrecognized OpenGL version
Jan 12 14:09:56 : Automatic GPU detection failed
Jan 12 14:09:56 : terminate called after throwing an instance of 'std::logic_error'
Jan 12 14:09:56 : what(): basic_string::_S_construct NULL not valid
Does Teradici need the Loopback device (That uses this file /usr/share/alsa/alsa.conf.d/10-rgs-loopback.conf)?
If the file exists when I start a Teradici session, then Flame will initialize audio if I pick either Alsa or PulseAudio in the Flame setup. In the application, the VU meters will bounce. However, no audio is being passed through Teradici.
If I remove the 10-rgs-loopback.conf file, and then start a Teradici session, system audio (the KDE startup chime) and Youtubes in Firefox will pass audio through Teradici. But Flame complains about not being able to find the 10-rgs-loopback.conf file, and audio will not initialize. In Flame audio preferences, the audio device is blank, and when I play something out nothing shows up in the VU meters.
I’m hoping that if I wipe it and set it up from the start for Teradici with Pulseaudio, it should just work? And without that loopback device?
Remote Workstation Card used ALSA, but Graphics Agent is Pulse Audio. But since Pulse is layered on top of ALSA, if RGS monkeyed around with ALSA config, it could make Graphics Agent unhappy. I imagine there’s something else that the RGS installer did that pointed to 10-rgs-loopback.conf, maybe look at file modification dates in /usr/share/alsa and compare with a system that hasn’t had RGS on it to try to bring it back to a pristine state?
It seems like RGS did make some changes in there. By checking the date modified in /usr/share/alsa, it appears that only the 10-rgs-loopback.conf file is new.
On a separate boot disk, I did a fresh install of Centos 8, and Flame audio worked fine through Teradici in that fresh Centos 8 install. So I’ll just finish setting that machine up.
My next step will be to get the NICs to keep their static IP addresses after reboots. We have two static networks, and sometimes they get swapped. I have some notes on how to do that in Centos 7 using udev rules, hopefully that still applies in 8.