Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with opening UI apps, display export problem? #97

Open
jensbrak opened this issue Sep 22, 2021 · 3 comments · May be fixed by #101
Open

Issues with opening UI apps, display export problem? #97

jensbrak opened this issue Sep 22, 2021 · 3 comments · May be fixed by #101

Comments

@jensbrak
Copy link

Have:

  • A Windows 10 pro machine with Virtualization and WSL2 setup
  • Installed Ubuntu via MS Store and verified it works
  • Installed xfce4 on Ubuntu WSL from shell in order to run full Desktop Manager
  • Installed GWSL via MS Store
  • Configured GWSL as per instructions (as far as I know)

Expected: UI apps started from Linux shell/Ubuntu WSL to pop up in Windows

Get: Nothing happens visually. Process for app starts and seems to run but is not visible. The process has a pid in the shell but window is just not to be found/seen.

Observations:

  • After installation/setup, GWSL has updated my .bashrc with some exports, notably the DISPLAY variable
  • DISPLAY is set to $(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0 which evaluates to the IP adress of my virtual machine IP which is the Ethernet adapter vEthernet (WSL) ip address under ipconfig
  • On a previous installation of Ubuntu under WSL I successfully ran xfce4 but only together with xrdp and connecting with mstsc (ie Remote Desktop) to it. I have not managed to get that working again after installing GWSL.

Test (which led me to post this "issue" which is more of a general question):

  • Manually setting the DISPLAY variable to my physical ip local adress rather than the virtual one. Then start an UI app from Ubuntu shell. App with UI starts and is displayed in a window in Windows - as I would have expected it to from the start.

In other words: export DISPLAY=<vEthernet WSL IP>:0.0 does not work
However: export DISPLAY=<Ethernet LAN IP>:0.0 does work as far as I can tell

Questions:

  1. What am I missing here? OR what assumption does the manual for GWSL do that I've missed, if any obvious by my rather short summary?
  2. Or does GWSL, in fact, have an issue of some sorts?
@Pololot64
Copy link
Member

It is not a bug in GWSL but a side effect of the complexity of Wsl networking. It breaks a lot. For gwsl I picked the display export method that works for most people. Every now and then, however, it does not work because there are too many unknowns.

@jensbrak
Copy link
Author

It is not a bug in GWSL but a side effect of the complexity of Wsl networking. It breaks a lot.

I understand and I appreciate what's been done already. It's amazing to be able to do this at all imho. I did some digging before posting my issue here and found several discussions that was in the same ball park as this. Since I did feel this case differed a little, I took the time to write it down anyway.

The basic concept is not hard to understand: A host machine (my Windows 10 rig) runs a virtual Linux machine, using hardware supported virtualization and Windows Subsystem for Linux. I assume the vEthernet adapter is the virtual network address for this virtual machine.

Let me try to formulate a question, or two to be precise: Is the issue here that the GWSL generated lines in .bashrc will get different kinds of ip for different combinations of distros and virtualization setups? Or is it that GWSL actually get the intended ip with the generated lines, but that for some people the WSL ip works and for others the physical ip?

If it is the former case I am quite happy with your explanation and how things are. I'm totally fine with having to adapt my Linux environment to export the apropriate DISPLAY variable. Perhaps it's possible to enhance documentation somewhere explaining what the DISPLAY variable should reflect in order to get it to work (as a complement to "just" automate the export of it). Or maybe I din't RTFM properly. Quite possible, if not likely.

On the other hand: if - for some reason - some people get GWSL to work using the physical ip of the host and others using the virtual ip, then I'm totally lost. Even if it's complicated under the hood, it does not make sense to me. I guess I have to dig deeper if this is the case and I want to know more.

In the end, I seem to have found a way (allthough manually only for now) to get things going so I'm quite happy with that. Thank you for your kind reply and all the effort made to make this amazing piece of software.

@Pololot64
Copy link
Member

I believe it is this "Or is it that GWSL actually get the intended ip with the generated lines, but that for some people the WSL ip works and for others the physical ip?" but I could be wrong. In some cases people have reported that it points to the dns when changed.

I would add something to the manual but I do not actually know another all encompassing alternative for the "non-standard" setups so I have not done that for that reason. If you can post your method I can add it with a note. :)

@hmnd hmnd linked a pull request Oct 9, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants