Allow openroad gui to run inside "make mount"

[maliberty]

Signed-off-by: Matt Liberty mliberty@eng.ucsd.edu

[maliberty]

This works for me and mostly addresses #484

[maliberty]

@msaligane FYI

[msaligane]

Yes, works for me too. Thanks @maliberty

[donn]

This is already supported by the current Makefile if you pass the environment variable DOCKER_DISPLAY=1.

[mithro]

FYI - https://blog.yadutaf.fr/2017/09/10/running-a-graphical-app-in-a-docker-container-on-a-remote-server/

[maliberty]

The DISPLAY_OPTION is missing the mapping of .Xauthority so it doesn't work for me. I don't see any reason for it to be an option (it's never harmful to have and non-obvious). #484 was not updated with this info. I don't see it in the docs.

I'll update this PR to handle the "ifeq ($(UNAME_S),Linux)" bit.

[mithro]

See also references at https://hdl.github.io/containers/ug/index.html#_tools_with_gui and https://github.com/ghdl/docker/blob/master/USE_CASES.md#environments-with-guis from @umarcor.

[donn]

The DISPLAY_OPTION is missing the mapping of .Xauthority so it doesn't work for me. I don't see any reason for it to be an option (it's never harmful to have and non-obvious). #484 was not updated with this info. I don't see it in the docs.

As we've discussed in our private weekly sync, I had no intention to document this option because I don't want to go around supporting different X setups. The .Xauthority thing is a perfect example: mine works fine without it, but yours won't. There's also the thing with ssh and --network host.

I'm not opposed to turning it on by default given your statement that it's never harmful, however.

[maliberty]

I expect the reason is that I ssh into another machine where I run the container and the DISPLAY is not local.

[umarcor]

As explained in the references provided by @mithro above, I strongly recommend using mviereck/x11docker and mviereck/runx (on Windows) in order to run GUI applications in containers.

• In essence, x11docker is a MIT licensed bash script (a single file) that handles the issues you've been discussing about (DISPLAY, Xauthority, etc.).
• Moreover, x11docker supports xpra, xephyr, wayland, weston... See https://github.com/mviereck/x11docker/wiki/X-server-and-Wayland-Options.
• The author of x11docker is very interested in the security of using containers (rather poor by default), so x11docker provides multiple thoroughly engineered options to make (remote) usage of containers as secure as possible.
• x11docker can be used as a CLI tool, providing a consistent interface regardless of the host OS or the specific X server. Alternatively, it has a GUI (https://github.com/mviereck/x11docker#gui-for-x11docker) which can be executed from a container.
• Using x11docker for building and/or running EDA tools with GUIs has been discussed and tested: Question: gui installer mviereck/x11docker#201.

See https://joss.theoj.org/papers/10.21105/joss.01349 and https://github.com/mviereck/x11docker/wiki.

Disclaimer: I've been involved in testing x11docker on Fedora and on Windows, as I pushed for adding Windows support to x11docker in order to ditch my multi-platforms scripts/makefiles.

[maliberty]

@umarcor It would be great if you can jump in with a PR implementing a better solution. I just got tired of people saying it doesn't work and passing around workarounds on gitter/slack.

[donn]

@umarcor @maliberty +1 - please do be advised though, if this changes our current container build system significantly or impedes headless operation in any form, it will not be merged.

The GUI support continues to be very much an at-your-own-risk-type deal.

[umarcor]

@maliberty unfortunately I am not familiar enough with the use cases of the makefiles in this repo, and why/when do users need a GUI and when they do not. It seems that a single Makefile is used for multiple use cases, including running tests, unattended usage or interactive usage. Hence, I can only suggest how to proceed by looking at the current mount target. The following target should be equivalent:

x11docker:
	cd $(OPENLANE_DIR) && \
		x11docker -i --user=0 $(X11DOCKER_OPTIONS) -- \
			-e PDK_ROOT=$(PDK_ROOT) \
			-v $(OPENLANE_DIR):/openlane \
			-v $(PDK_ROOT):$(PDK_ROOT) \
			$(DOCKER_OPTIONS) \
			-- $(OPENLANE_IMAGE_NAME) \
			bash

At the same time, remove from DOCKER_OPTIONS all the stuff related to DISPLAY, xauth, etc. (x11docker takes care of it).

X11DOCKER_OPTIONS can be used for providing custom options to x11docker. For instance, on MSYS2 I would use X11DOCKER_OPTIONS=--runx --no-auth, because I use VcxSrv as the X server.

@donn, the x11docker target should be completely unrelated to the build system, the execution of tests, or any other usage of the makefile. It is used for passing PDK_ROOT, OPENLANE_DIR, DOCKER_OPTIONS and OPENLANE_IMAGE_NAME to the container. Any other approach to pass those arguments would work. In fact, I believe that the x11docker target might be written in a different makefile, which includes the current one.

[grant-h]

Note that on Ubuntu 20.04 --security-opt apparmor:unconfined is also required to be added to DOCKER_OPTIONS. Otherwise you'll get issues like audit: type=1107 audit(1680185873.107:2557): pid=1232 uid=103 auid=4294967295 ses=4294967295 subj=unconfined msg='apparmor="DENIED" operation="dbus_signal" in dmesg when running KLayout which says:

OpenLane Container (4cd0986):/openlane$ klayout -e -nn $PDK_ROOT/sky130A/libs.tech/klayout/tech/sky130A.lyt \
>    -l $PDK_ROOT/sky130A/libs.tech/klayout/tech/sky130A.lyp \
>    ./designs/spm/runs/openlane_test/results/final/gds/spm.gds
process 13: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
  D-Bus not built with -rdynamic so unable to print a backtrace