• Windows 10 Build 18922

Unlike WSL1, you cannot use 127.0.0.1 or localhost to connect back to Windows; when you start WSL2, it gets its own IP address and behaves like a Hyper-V virtual machine. Microsoft seems to be working on changing this behavior and support shared loopback addresses just like WSL1 but it's not yet happened.

Anyhow, if you don't want to wait for the official release of WSL2 or support for the shared loopback addresses, you can make the following changes and use Linux GUI apps in WSL2 with X410.

  • Enable 'Allow Public Access' option in X410

    When you first install X410, it only allows connections from loopback addresses such as 127.0.0.1 for security reasons. But WSL2 is started with its own IP address and behaves like a virtual machine in a separate network. So if you want to have Linux GUI apps in WSL2 show up on Windows, you first need to allow connections from any device including WSL2 for X410. This option is found in [ X410 Tray-icon Popup Menu ] » [ Allow Public Access ].

    When you enable this option for the first time, you'll see a 'Windows Security Alert' popup window for your confirmation about allowing X410 to accept connections from public network. You need to allow this 'Public' access in order to have Linux GUI apps in WSL2 communicate with X410 running in Windows.

    For your information, you may see a similar 'Windows Security Alert' popup window again when X410 is updated to a new version; it seems Windows Firewall treats each executable version separately even though they all belong to the same Microsoft Store app. Such behavior also leaves multiple 'x410.exe' entries in Windows Firewall; you can safely remove those 'x410.exe' entries from previous versions.

    Please also check Windows Firewall settings and make sure X410 is allowed for 'Public' access.

    If you're concerned about security risks for allowing such public access, you can configure Windows Firewall and allow connections to X410 only from WSL2. Please consult Windows Firewall documentation for additional information.

  • Update DISPLAY environment variable

    WSL2 has its own IP address and doesn't yet share loopback addresses; when you're connecting to 127.0.0.1, you're actually connecting to WSL2 rather than the underlying Windows. So you need to directly use the IP address assigned for Windows.

    We recommend using the internal IP address that is automatically added to '/etc/resolv.conf' file in WSL2. This address may get changed periodically. So you should dynamically extract an address from the file when assigning it to the DISPLAY environment variable:

    export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
    
    
    
    
  • Test if X410 is reachable from WSL2

    If you're familiar with 'nc (netcat)' command, you can use it for testing the connections between Windows and WSL2 without actually running a Linux GUI app.

    1. Get the IP address of Windows

      You should already have set the DISPLAY environment variable as mentioned above. This variable contains the IP address that is used by Linux GUI apps for connecting back to X410 in Windows.

      echo $DISPLAY
      
      
      
      
    2. Run 'nc'

      Let's assume the IP address revealed in Step 1 is '172.30.32.1'. Execute the following command while X410 is running:

      nc -v 172.30.32.1 6000
      
      
      
      

      You should get the following message if X410 can be connected and ready for WSL2:

      Connection to 172.30.32.1 6000 port [tcp/x11] succeeded!
      
      
      
      
      

      If you're getting the following, there is a problem with Windows network and/or firewall settings. Please review the settings mentioned above again and make sure they're properly configured. Also, if you're using third-party security software, make sure WSL2 and X410 are not blocked or quarantined.

      nc: connect to 172.30.32.1 port 6000 (tcp) failed: Connection refused
      
      
      
      

    Please keep in mind that WSL2 is in its 'preview' stage and it's only available for an 'Insider' version of Windows. So there can be problems and corrupted settings while updating apps and Windows. Such problems may automatically be fixed in the next Insider version or by simply uninstalling-rebooting-reinstalling X410.

  • Linux GUI apps stopped working after waking up from Windows sleep mode

    WSL2 seems to have inherited this problem from Hyper-V. You can avoid this issue in Hyper-V by using VSOCK. But, unfortunately, WSL2 doesn't yet support VSOCK or other methods that can be used for avoiding this problem. We'll update this page as soon as we find a workaround or when Microsoft fixes it! Stay tuned.