ROOT on Windows 11 WSL2 / WSLg

ROOT
1

Dear experts/developers,

I installed the latest ROOT (6.24/06) on a Windows 11 with WSL2 (which has native GUI support) and found a weird problem with graphics.

Some details:

It is not a fresh Windows, but updated from W10, although it did not have WSL installed before, so it is a fresh WSL install.

As per the recommended ROOT instructions

with this post from @James-Carroll

and MicroSoft’s instructions for WSL, I did this (with reboots where needed):

  1. Turned on these Windows features: “Virtual Machine Platform” and “Windows Subsystem for Linux”, although it seems that the first one (VM) is not really needed, as I don’t have it enabled in a Windows 10 machine and Ubuntu and ROOT run well, with WSL1.
  2. Contrary to MS’s suggestion, I did not install a vGPU driver (see further below), as I expected it should only/mainly affect performance, but not compatibility.
  3. Installed WSL and updated it; it automatically chose WSL2 (no need to change as is needed in W10).
  4. Installed Ubuntu 20.04 LTS and updated it.
  5. Installed ROOT dependencies (from above post), and ROOT (precompiled).

I did not install an X server, which should not be needed in this case.

With the above, ROOT runs and I am able to open TBrowser and TCanvas windows, for instance, but it is impossible to interact with them; and by the way, these windows also take several seconds to show up, so graphics performance seems worse than with WSL1 and an X server, at least for ROOT.
When clicking on any option (e.g. File, Edit,…), or right-clicking, the dropdown menus show up in apparently random (different every time) places on the screen. Moving the mouse as if the menu were in the right place shows that the ‘cursor’ is moving in those dropdown popups, because the options get highlighted accordingly, but clicking does nothing; looks like the mouse movement is going to those popups but the clicks are going where the mouse is actually located; if the mouse is hovered on the popups, these don’t react (they don’t know the mouse is there).

Here is a view showing an example:

Screenshot_2022-01-12 10-47-22_cr
Screenshot_2022-01-12 10-47-22_cr1390×740 123 KB

I already installed the vGPU driver, for AMD in my case, and it did not fix it; in fact, the screen capture was done after installing this driver.

I’m wondering if anybody has seen something similar or it’s just my system --maybe not an issue with Intel or NVIDIA graphics?

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.24/06
Platform: Windows 11
Compiler: Not Provided

2

@bellenot, have you seen this issue before?

3

Nope, but I don’t have Windows 11 and I only tested on WSL (1 IIIRC) with a X Server. And I mostly work on native Windows (e.g. not on WSL)

4

@dastudillo any chances that you can try native 32-bit ROOT on Windows or WSL1 instead?

5

Or try with a X Server

6

@jalopezg & @bellenot Indeed I was planning to try first with an X server and WSL2, although it might get crazier, since WSL2 on Windows 11 is supposed to have its own graphics server, which may collide with an X server :slight_smile: If that fails I will try switching to WSL1. I will write back as soon as I have updates.

1 Like
7

So I tried staying with WSL2 and using VcXsrv, and it works fine, as far as I have tested.
I don’t know if behind curtains WSL is complaining for having 2 GUI servers, but it seems to work :slight_smile:

Just for completeness, when using WSL2 and VcXsrv (don’t know with Xming), adding these lines to .bashrc is needed:

export DISPLAY=$(awk '/nameserver / {print $2; exit}' /etc/resolv.conf 2>/dev/null):0
export LIBGL_ALWAYS_INDIRECT=1

but is not enough (in either Windows 10 or 11). When starting XLaunch, which always asks for some settings, one has to also activate the option “Disable access control” (in “Extra settings”), which is unchecked by default. This option is not needed when using WSL1 (and .bashrc only needs export DISPLAY=localhost:0.0 at least in the systems I’ve tried).
image

1 Like
8

Cool, thanks for the feedback @dastudillo !

1 Like
9

WSL1 doesn’t use virtualisation technology, it runs a compatability layer that translates system calls directly, so you don’t need the VM components active for WSL1.

From my understanding of WSLg’s architecture, if you adopt a third party XServer instead, there shouldn’t be any conflicts, but of course, you’d be expected to set the $DISPLAY variable manually, as you have done.

The LibGL part of the equation is more complex and I couldn’t give a direct answer as to when it’s needed, but the simple logic behind it is that it sends GPU commands to the client (Windows) over the network to run instead. The caveat is that it limits these commands to an OpenGL 1.1 specification, which is old and generally not even used; so to some degree it also indirectly just toggles off a lot of OpenGL use. And of course, a big part of WSLg was to enable GPU paravirtualization, which means that in most cases where the driver supports it, you’d just want to run it on the Linux side for simplicity’s sake, given it’s actually the same GPU in both environments.

While I can’t say exactly the issue, the problem is that WSL2 uses a virtualised network adapter since it is actually a Virtual Machine. It has a second IP address on the system that can appear foreign to the Windows side of things. WSL1 uses the same network adapter / network interface as the host and appears much more native, so would be indistinguishable from localhost and not need to change security settings. Personally, this aspect of WSL2 upsets me the most, besides the lack of proper systemd support.

Finally, with the problem of the right click menu being completely disjoined from the display; I can’t offer any answers but I would suggest you report it on WSLg’s Github.

4 Likes
10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

11

Update to this thread here: https://root-forum.cern.ch/t/root-on-wsl2-windows-11-and-ubuntu-update-sep-2024

1 Like