Unsure on GUI connection for non-Linux hosts

tomeichlersmith commented 7 months ago

Context In ldmx-env.sh, we need to go through a whole rigamarole to deduce the OS so we can pass the correct DISPLAY environment variable to docker:

https://github.com/LDMX-Software/ldmx-sw/blob/e0c6003f16031ca768b0622c38aa24c29cea296e/scripts/ldmx-env.sh#L57-L74

https://github.com/LDMX-Software/ldmx-sw/blob/e0c6003f16031ca768b0622c38aa24c29cea296e/scripts/ldmx-env.sh#L160-L167

Currently, I've only tested denv manually on Linux hosts whose GUI applications are connected pretty cleanly by the auto-mounting of /tmp and the forwarding of the DISPLAY environment variable from the host environment.

What are you trying to do?

I'd like to make sure denv can share GUI applications with the host whether the host is Windoze via WSL or MacOS. I don't have a direct way of testing this, so I may need to rope some friends into helping test this for me :eyes:

It looks like WSL has been updated to support forwarding GUI applications with the help of a few environment variables. https://github.com/microsoft/wslg/blob/main/samples/container/Containers.md

I can't find anything on MacOS signalling an update relative to whats in ldmx-env.sh on the first page of google.

tomeichlersmith commented 2 weeks ago

I just ran the non-interactive tests ./ci/test docker and the GUI test on a friend's Windoze laptop within the subsystem for Linux. All the tests passed :tada: including launching and interacting with xeyes (it looks like WSL was updated to avoid the more complicated interaction that was necessary when ldmx-env.sh was written).

Observations

Tests took a bit longer I'm guessing since the images needed to be downloaded but maybe because of the extra WSL emulation layer.
xeyes only interacted with the mouse when it was within the window itself. This is probably originating from the fact the Windoze's windowing system is different from the X11 server it is hosting for WSL. Hopefully no programs rely on being able to observe the mouse position when it is outside the window of the program itself!

tomeichlersmith commented 2 weeks ago

Worked with a friend @tvami on trying to connect to GUI on a MacOS host and things did not work as seamlessly as I'd hoped. It is not working without some external configuration and these are the things we tried.

Set Up

This isn't exactly what was done, but just points out that the image we used was the one built from the test/gui/image context.

cd test/gui/image
docker build . -t denv-gui-test-image

Summary

After some trial and error, I think the biggest summary is that the following command

docker run --rm -it -v /tmp/.X11-unix:/tmp/.X11-unix --user 501:20 -e DISPLAY=docker.for.mac.host.internal:0 denv-gui-test-image:latest xeyes

Returned

Error: Can't open display: docker.for.mac.host.internal:0

But, Updating XQuartz and making sure configuration was correct resolved the issue :tada: Specifically, adding localhost as an allowed source xhost + 127.0.0.1 is what really helped.

tomeichlersmith commented 2 weeks ago

Another helpful gist, I'd really like to automate the checks below so that denv check could inform users if GUI interaction is expected to be functional or not but I'm not expecting that to be easily developed by me since I don't have a MacOS machine.

# pseudo-code
XQuartz is installed || ERROR("Need to install XQuartz for GUI interaction.")
XQuartz is running || ERROR("XQuartz needs to be running for GUI interaction.")
Network Clients are Allowed || ERROR("Configure XQuartz to allow network clients.")
Localhost Client is Allowed || xhost + 127.0.0.1
MESSAGE("GUI Should work")

tomeichlersmith / denv