Problem with Qubes4 rc4 -- "GLX is not supported."

[bill...@gmail.com]

I've installed Qubes 4 rc4 on an external hard drive. It works pretty well. However, I tried to run a game "FreeOrion" and received the following error using the "personal" vm:

****************
Unable to create window.

SDL reported:
GLX is not supported
**************

I took a look at what drivers were loaded, and at least at the level of lsmod in dom0. The difference between Qubes and my "regular" linux distribution (KDE neon) was that under qubes, the module amdgpu was not loaded.

%lsmod | grep radeon

radeon 1658880 1
ttm 114688 1 radeon
i2c_algo_bit 16384 2 radeon, i915
drm_kms_helper 192512 2 radeon, i915
drm 438272 8 radeon, i915, ttm, drm_kms_helper

%lsmod | grep amd
amdkfd 147456 1
amd_iommu_v2 20480 1 amdkfd

After running "modprobe amdgpu" in dome0:

%lsmod | grep amd

amdgpu 2072567 0
amdkfd 147456 1
amd_iommu_v2 20480 1 amdkfd
ttm 114688 1 amdgpu, radeon
i2c_algo_bit 16384 2 amdgpu, radeon, i915
drm_kms_helper 192512 2 amdgpu, radeon, i915
drm 438272 8 amdgpu, radeon, i915, ttm, drm_kms_helper

I'm still not clear on how video works, since none of these show up when I run lsmod in the personal vm or the fedora 26 template. But in any case, nothing changed when I then tried to run the game. I closed the personal vm and restarted it, but nothing changed.

lspci in dom0 reveals

Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 ?M430 /R7 M520] (rev 81)

(please excuse any typos, I'm having a little trouble copying and pasting text from dom0, so I typed the above in by hand).

What should I try next?

Thanks,

billo

[donoban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/06/2018 04:02 PM, bill...@gmail.com wrote:
> I've installed Qubes 4 rc4 on an external hard drive. It works
> pretty well. However, I tried to run a game "FreeOrion" and
> received the following error using the "personal" vm:
>
> **************** Unable to create window.
>
> SDL reported: GLX is not supported **************
>

If the game needs 3D acceleration it will not run on an AppVM or HVM.
You can try with VGA passtrough but is not easy to achieve.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlp8U7wACgkQFBMQ2OPt
CKX0sA//biGyKJr+FgLi2ZDkg6TnzvHOipO0rrKEsvttA2FqRW2CNe3IYBen3tiM
QdYQvw4fbxMEtNIWZnk0B+5em0ZF28g44kw32p0p+GFu0kxGAKN6hdBxdrI/9vVT
09vZ4+hdgoTzcH+cSvQW3x5lo3CFYg2SqkycU8TlBXhfU9BqQNv502is+rY7kLmu
Pt5E+HEMPjEnxyDAm79NiqAjf9I9JBrph++Ti5EkbOLfxIjSOCss8tnIg+/nioXh
Nn6QgSTas4uzn7nQ3c1/emBK7cUQaVPi1udSjcnaJtGguWi6N/8uDBbfHUwbt761
Cg41K870rE6iSYpDqNHa+Un5h3vDhzsIEE7E0MneXQ/pG2K8aDGzZ9BL3QOFCa/M
bQoLzL6biXL2vK9av8gBOGb1IB756Zfwu56zCkFWT3dTnA4LRJYPrlqygumJoFG+
nOhagTJcMljuFcCWwZhphuQR14hfThm1h5bpeqATrMJp6dq1ro64EE4nuerm8iNK
9Dlwu8eNxp2TLqQwvZ4nT7QzcvA8TyHJqeqRmbLnOdNHpwJIbmnixPYqgwiScOmc
WXhGNwoc88oAwlr5+dJ1eJHJxJEWvgam6Xjozs6H5P3qYYXCDeiI4uKRiO7tCEJF
2Z5snT/hqJCmVc8rZPbEiSgFAJq6NIanlzmDEq2Rcm1HlQnd4XI=
=vetq
-----END PGP SIGNATURE-----

[Yuraeitha]

As donoban also said, Qubes does not yet support high end graphic applications, but while nothing is official, the keyword here is "yet".

Once the security implications are solved, and enough resources and time can be allocated to make it work without taking away from the many other much higher priorities, like security, then we'll likely see high-end graphics available in Qubes. But Qubes also have really, really high security standards, it will probably never see the day of light if the security aspect is not solved first. Which is also *the* reason you can't use high-end graphics or game on Qubes at the moment. But as you probably noticed by context, this changes if above issues are overcome.

There are new approaches and proof of concept designs up for discussion, for example on github, but it's too early to say where all this goes. It does seem like new proof of concept designs might solve the security issue though, but no conclusions on this matter can be found yet, not on open channels that I'm aware of anyway. Keep being patient, and perhaps if we're lucky we'll see this coming.

[bill...@gmail.com]

Thanks all, for your replies. So, it's a feature, not a bug :-). That's cool -- I mostly just need to know to stop trying to fix it. For the moment, it's not a big deal. Most of my work does not involve fancy 3D graphics, and I can easily boot into something else for that.

[bill...@gmail.com]

Thanks. That's what I needed to know.

[Yuraeitha]

On Saturday, February 10, 2018 at 4:26:12 PM UTC+1, bill...@gmail.com wrote:
> Thanks. That's what I needed to know.

You're welcome (: I know the feeling, it would suck to do so much work only to find out it's not feasible or possible.

Maybe dual-boot or have two computers can solve your needs until it becomes possible in Qubes?

I know it sucks, I grapple with this issue my self as well. The day high-end graphics becomes available on Qubes OS, will truly be an amazing day, just for the ability to ditch a second laptop/desktop for high-end graphics alone... uhue...

btw, there is some discussion on dual-boot with Qubes that you may read up on if you haven't done so already. There are risks associated with it, but it may only be risks for high profile attacks, currently at least. So it may be justified to dual-boot still. However, even if a low profile target, it can put some ease of mind to get rid of as many attack vectors as possible. I guess it depends on personality on how to grabble and go about the risk factors, so it's up to the individual on what is feeling better to do after considering the risk factor.

You can also dual-boot with, say, Fedora, and then virtualize, say, Windows, on Fedora. It might not be as perfect as on Qubes OS, but if you dual-boot with Fedora, and keep Windows virtualized inside Fedora, at least it should reduce some attack vectors, albeit, not all of them.

[Jean-Philippe Ouellet]

On Thu, Feb 8, 2018 at 8:42 AM, donoban <don...@riseup.net> wrote:
> On 02/06/2018 04:02 PM, bill...@gmail.com wrote:
>> I've installed Qubes 4 rc4 on an external hard drive. It works
>> pretty well. However, I tried to run a game "FreeOrion" and
>> received the following error using the "personal" vm:
>>
>> **************** Unable to create window.
>>
>> SDL reported: GLX is not supported **************
>>
>
> If the game needs 3D acceleration it will not run on an AppVM or HVM.
> You can try with VGA passtrough but is not easy to achieve.

However... just because there's no hardware acceleration does *not*
mean that 3d in AppVMs is impossible.

Depending on the application, software-only 3d rendering may be
sufficient. Many games (especially older and/or indie ones) are indeed
still playable, and 3d cad stuff is also often usable.

There are several software implementations of the OpenGL, etc. APIs,
most notably llvmpipe, softpipe, and (open)swr. Search the qubes-users
archives for these, and look for posts from Vít Šesták. [1]

The software implementations tend to lag behind actual GPUs in terms
of the subset of the OpenGL API that they actually support. More info
at [2]

Which renderer is used is controlled by setting envirionment variables
interpreted by mesa/gallium drivers. For example, to make some games
run I've had to lie about the supported OpenGL version by setting
MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERSION_OVERRIDE, or switch the
renderer with LIBGL_ALWAYS_SOFTWARE and GALLIUM_DRIVER. I'm not going
to list any specific values here since they would quickly become out
of date. Instead, refer to the documentation about these env vars at
[3] and play with them yourself. You may find the glxinfo command from
the glx-utils package useful to make sure your env vars are having the
intended effect.

Regards,
Jean-Philippe

[1]: https://groups.google.com/forum/#!searchin/qubes-users/llvmpipe%7Csort:date
[2]: https://mesamatrix.net/
[3]: https://www.mesa3d.org/envvars.html