Win10 linux subsystem libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast

Question

I'm not really asking a question, but this ___ website won't allow me to do this any other way.

I ran into a problem today using GTK under Win10's Linux subsystem (specifically Ubuntu 18.04). The error msg was:

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

Someone else ran into this while using Steam, and there are some answers here: Steam libGL error. The second answer, "Windows Subsystem for Linux (WSL) has same error", is the one that led me to the solution, however that answer didn't work out of the box.

Their answer concerns a directory /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1. That directory does not exist in my system, but I'll provide the solution that did work on my stem in my answer (to myself).

I realize this is a terribly clumsy way to answer this question. However, I felt it was important to answer it, because it took me a lot of fiddling around to find an answer that worked for me, and others may have the same issue. I couldn't leave an answer on the original question, because it's been closed; and I couldn't comment on the answer that led me to the solution, because I don't have sufficient reputation. And I couldn't post to the meta-questions either. Can you say "Catch-22"? I knew you could.

Answer 1

Add LIBGL_ALWAYS_INDIRECT variable to /etc/bash.bashrc solved my error.

export LIBGL_ALWAYS_INDIRECT=1

Don't know what's the actual usage. But maybe useful, because XLauch confg says it requires this.

My error occurs when invoke emacs from wsl2, and display in XLauch (vcxsrv):

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

I find the solution according to:

• The Ultimate Emacs Hacking Tutorial in Windows 10 WSL 2
• Does WSL support openGL?

Answer 2

Again, apologies for answering my own question, but this seems to be the only way to put up an answer to the problem, as I detailed in my question.

On my Win10 Linux Ubuntu subsystem, the mesa drivers were in this directory: /usr/lib/x86_64-linux-gnu/; unlike the answer linked to above, there was no Mesa (or mesa, or...) subdirectory. So I created a tmp dir somewhere else, and moved the mesa drivers (two, plus two links) to that tmp dir. And now my GTK-based app works.

The two drivers were /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0.0.0 and /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0; the two links were /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0 and /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0. The cmd to move the files was sudo mv /usr/lib/x86_64-linux-gnu/*mesa* tmp/ (make sure the tmp/ dir is not in a place where library files live).

I make no claims about whether the mesa drivers are needed for something else, which is why I moved them to a tmp/ dir rather than deleting them. But after moving them, my GTK app worked.

Answer 3

If you configure Xlaunch it via UI, in the additional parameters add -nowgl

-[no]wgl
    Enable the GLX extension to use the native Windows WGL interface for hardware-accelerated OpenGL

Answer 4

On WSL2 with Ubuntu 20.04:

1. don't set LIBGL_ALWAYS_INDIRECT (remove the export from your .bashrc or .profile)

2. Set Wgl="False" in your XLaunch configuration

See this comment on GitHub.

Answer 5

For me, moving libraries didn't help. However, updating mesa drivers did.

The easy way to verify whether a problem is present is to run glxinfo | grep "OpenGL version"

Then follow this installation guide which had the right mesa repo for my Ubuntu 16.04 (WSL).

Once updated, you can verify with glxinfo that the problem disappeared.

Answer 6

You can set up your XLaunch configuration (type XLaunch in your search bar), or directly start XServer in a Command Prompt :

"C:\Program Files\VcXsrv\vcxsrv.exe" :0 -multiwindow -clipboard -nowgl -ac

-ac to disable access control (to prevent connection error)
-nowgl as stated by others.