Hello all,
Im in the process on getting an mri pipeline up and running using WSL2, and I have X11 forwarding working using Vcxsrv(other X11 apps open fine, Xeyes etc). However mrview will not open, when I run mrview -debug I get the following output:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
mrview: [DEBUG] No config file found at "/etc/mrtrix.conf"
mrview: [DEBUG] No config file found at "/home/user/.mrtrix.conf"
mrview: [INFO] GL renderer: softpipe
mrview: [INFO] GL version: 1.4 (3.3 (Compatibility Profile) Mesa 22.0.0-devel (git-7aab7ccd36))
mrview: [INFO] GL vendor: Mesa/X.org
mrview: [WARNING] unable to determine OpenGL version - operation may be unstable if actual version is less than 3.3
mrview: [DEBUG] loading font into OpenGL texture...
mrview: [DEBUG] compiling OpenGL vertex shader:
#version 330 core
layout(location = 0) in vec2 pos;
layout(location = 1) in vec2 font_pos;
uniform float scale_x;
uniform float scale_y;
out vec2 tex_coord;
void main () {
gl_Position = vec4 (pos[0]*scale_x-1.0, pos[1]*scale_y-1.0, 0.0, 1.0);
tex_coord = font_pos;
}
mrview: [DEBUG] compiling OpenGL fragment shader:
#version 330 core
in vec2 tex_coord;
uniform sampler2D sampler;
uniform float red, green, blue;
out vec4 color;
void main () {
color.ra = texture (sampler, tex_coord).rg;
color.rgb = color.r * vec3 (red, green, blue);
}
mrview: [DEBUG] font loaded
QOpenGLFramebufferObject: Unsupported framebuffer format.
mrview: [SYSTEM FATAL CODE: SIGSEGV (11)] Segmentation fault: Invalid memory access
user@DESKTOP-98R86B5:~$ xeyes
user@DESKTOP-98R86B5:~$ xterm
user@DESKTOP-98R86B5:~$ mrview
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user'
mrview: [WARNING] unable to determine OpenGL version - operation may be unstable if actual version is less than 3.3
QOpenGLFramebufferObject: Unsupported framebuffer format.
mrview: [SYSTEM FATAL CODE: SIGSEGV (11)] Segmentation fault: Invalid memory access
Any help in getting this working would be greatly appreciated! I checked all of the other threads regarding wsl2 and mrview and I have tried everything I’ve seen to no avail.
Best,
Mike
Hi @mglassen,
OK, if you’re using WSL2 on Windows 11, you should not need to run a separate X11 server. Instead, applications running on WSL2 should be able to render using the more modern Wayland protocol. This is now the standard display stack for the most recent Linux distributions, with X11 gradually being phased out. Microsoft provides support for Wayland rendering using a modification of their remote desktop protocol (RDP) (details here for the interested reader). For legacy X11 apps, there is the xwayland package, which provides a compatibility layer (basically runs an X11 server on top of Wayland) – again, that can be done within the Linux guest, no need for an external 3rd party X11 server.
This should all work out of the box – provided the client Linux distribution includes the necessary support for Wayland rendering. I can’t remember the exact packages required, but hopefully they won’t be hard to figure out. And the chances are, they’re already installed anyway…
What we have found is that sometimes you need to update the GPU drivers on the host Windows system, so that WSL2 can properly interact with the GPU and provide the virtual interface to the GPU that the Linux guest needs to communicate with. So as a first step, I’d recommend simply updating your graphics drivers and restarting your system – you might find that’s all that’s needed…
Best of luck,
Donald.
I’m running windows 10 and Ubuntu 20.04 with wsl2, would Wayland rendering still work in this case?
Ah, not sure about Windows 10… It looked like they were going to add support for this a while back, but then they did, and now they’re dropping support for Windows 10 altogether, so to be honest, I have no idea…
Ok, as an alternative would creating a docker container of Ubuntu 20.04 on that computer work easier do you think?
No, I don’t think so – getting GUI applications to work on Docker is even harder, and most likely won’t work well even if you do manage to get something going. It may be possible for simple X11 applications, but as soon as you throw OpenGL 3+ in the mix (which is what we use for 3D rendering), then it’s no longer supported by standard X11. Besides, WSL2 is also essentially a container, so I don’t think there’s anything you can do in docker that you couldn’t in WSL2.
Personally, I think your best bet is to upgrade to Windows 11 if that’s at all an option. If nothing else, Microsoft will end all support for Windows 10 next year.
Having said that, I just had a closer look at the specs for the computers that we used to run our last workshop in Taiwan, where we did use WSL2, and it looks like we were indeed running on Windows 10 (maybe @chunhungyeh can confirm…?). For those systems, we did need to update the Windows GPU drivers to get the display working, but it was all (mostly) fine after that. So assuming I’ve got that right, WSL2 on Windows 10 should definitely be possible!