To be more precise, the games actually start (music is playing) and do not crash, but nother is ever displayed. If I set LIBGL_DEBUG=verbose, I get the following:

libGL: pci id for fd 4: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/radeonsi_dri.so
libGL: Using DRI3 for screen 0
Setting breakpad minidump AppID = 236850
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198007143817 [API loaded no]
function is no-op
function is no-op
function is no-op
function is no-op
function is no-op
function is no-op

The last lines repeat endlessly.

For reference, I compiled Mesa git and the issue remains unchanged.

After further investigation, I have found:
1. The games will start correctly if the launcher is bypassed
2. The games will start correctly only if the "multi_sampling" option is set to 0 in the respective settings.txt files.

I suspect that the launcher ignores settings.txt and sets multi-sampling anyway.

It seems that I was running Wayland by accident. It works under X.org. Though as I assume that things should keep working with Wayland too, I leave the bug open for now. Feel free to close it otherwise.

Please attach the output of glxinfo in Wayland and Xorg sessions.

Created attachment 127350 [details]
glxinfo under an X session

Created attachment 127351 [details]
glxinfo uner a Wayland session

Hello Michel. I have attached the files. Note that since the last report I reverted back to a 4.7 kernel as the new one was having issues with ACPI flooding the logs. The issue is unaffected though. Thanks!

Same happens on Intel drivers with a standard Fedora 25 session. Seems the steam/stellaris app don't fall back properly to XWayland session, so sound yes, picture no. I changed the product to reflect the correct issue source.

We just patched the launcher to not enforce any msaa at all. Dunno when it will be in the different games, but you will still need to set your msaa to disabled if this is the case.

We are using the old GL_ARB_multisample for this and nothing fancy in our shaders so I believe this indeed is a xwayland issue and not application.

If you need any more info or advice pls let me know.

best regards,
Gustav Palmqvist

Created attachment 128702 [details]
errors under wayland when launching stellaris.

here are the errors that occurr when the game attempts to launch under wayland.

Created attachment 128703 [details]
normal startup under X11

seems like wayland causes glxinfo to report different opengl capabilities?

diff wayland-glxinfo.txt xorg-glxinfo.txt | head -50
7,8c7,9
<     GLX_ARB_create_context, GLX_ARB_create_context_profile,
<     GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample,
---
>     GLX_ARB_create_context, GLX_ARB_create_context_profile, 
>     GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
>     GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample,
12,14c13,15
<     GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method,
<     GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
<     GLX_SGIX_visual_select_group, GLX_SGI_make_current_read
---
>     GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
>     GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
>     GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
34,39c35,41
<     GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB,
<     GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age,
<     GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile,
<     GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB,
<     GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info,
<     GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
---
>     GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float,
>     GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample,
>     GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
>     GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float,
>     GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context,
>     GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating,
>     GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer,
44c46
<     GLX_SGI_video_sync
---
>     GLX_SGI_swap_control, GLX_SGI_video_sync
50c52
<     Video memory: 7994MB
---
>     Video memory: 8039MB
300c302
< 192 GLX Visuals
---
> 480 GLX Visuals

This is still an issue under a Wayland session in Ubuntu 17.10: For Europa Universalis 4, the launcher does not show up on screen and and neither does the game itself.

The launcher for Stellaris and the game are working correctly for me now with a Wayland session as of Fedora 26 (for whatever that means in terms of major versions). I have Intel integrated graphics.

I was looking at something almost completely unrelated and I think I came across the root cause of this bug.  Currently, XWayland does not advertise support for any multisampled visuals.  You can reproduce this trivially with "glxgears -samples 4".  Hidden in comment 13 is this nugget:

(In reply to pandiculationfinch from comment #13)
> 300c302
> < 192 GLX Visuals
> ---
> > 480 GLX Visuals

I think the root cause here is that XWayland loads swrast for indirect GLX instead of figuring out which actual DRI driver to load.  Since swrast does not support multisampling, we get no multisampled visuals.  I don't really know the internals of XWayland enough to know how to fix that problem but there it is.

Adam Jackson just submitted a fix for this issue (https://gitlab.freedesktop.org/xorg/xserver/merge_requests/195)

(In reply to Christian Schaller from comment #17)
> Adam Jackson just submitted a fix for this issue
> (https://gitlab.freedesktop.org/xorg/xserver/merge_requests/195)

Thank you (+ everyone involved).

Just out of curiosity: I've seen someone who mentioned this bug in the comments of your blog post about Fedora Workstation 30. Was that actually a trigger to fix it or did you prioritize the bug due to other reason and it just happens to fix this bug as well?

Hi Felix,
Actually it was the blog comment that made we aware of the issue and which in turn made us prioritize getting it fixed :)