devcontainer, how to make X display work (mount graphics inside docker in visual studio code)

Question

Normally I use this trick to make X work inside docker:

docker run --rm -it -v /tmp/.X11-unix:/tmp/.X11-unix -v $HOME/Videos:/videos -e DISPLAY=unix$DISPLAY --name knl kdenlive

I tried doing the same on a devcontainer:

{
    "name": "example_dockerized_environment",
    "dockerFile": "Dockerfile",
    "extensions": [
        "ms-vscode.cpptools",
        "twxs.cmake",
        "eamodio.gitlens"
    ],
    "mounts": [ "source=../,target=/home/project", "source=/tmp/.X11-unix, target=/tmp/.X11-unix"],
    "containerEnv": {
        "DISPLAY": "unix:0"
    },
    "runArgs": ["--privileged"]
}

As you can see, I passed unix$DISPLAY and also mounted X11-unix

But I get

root@5e6a10efbea6:/workspaces/leuze_lidar_volume/sdk/quanergy_client-master# ./visualizer --host localhost
ERROR: In /build/vtk6-YpT4yb/vtk6-6.2.0+dfsg1/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 1466
vtkXOpenGLRenderWindow (0x2293740): bad X server connection. DISPLAY=Aborted (core dumped)

When I do echo $DISPLAY inside docker I see nothing. I tried doing

export DISPLAY=unix:0 then I get

root@5e6a10efbea6:/workspaces/leuze_lidar_volume/sdk/quanergy_client-master# ./visualizer --host localhost
ERROR: In /build/vtk6-YpT4yb/vtk6-6.2.0+dfsg1/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 1466
vtkXOpenGLRenderWindow (0x281dcf0): bad X server connection. DISPLAY=unix:0. Aborting.


Aborted (core dumped)

I also see no /tmp.x11-unix inside the container:

root@5e6a10efbea6:/tmp# ls -la /tmp 
total 16
drwxrwxrwt 1 root root 4096 Mar 18 03:47 .
drwxr-xr-x 1 root root 4096 Mar 18 03:45 ..
srwxr-xr-x 1 root root    0 Mar 18 03:42 vscode-git-askpass-c2ca47727522d7940b4cce1d99fcc88d32ccfefc.sock
srwxr-xr-x 1 root root    0 Mar 18 03:47 vscode-git-ipc-f52b0dbfd870db22481ea656170b7615ea1e6497.sock
srwxr-xr-x 1 root root    0 Mar 18 03:45 vscode-ipc-032f3099-16ea-4f5d-8561-586571a4aea9.sock
srwxr-xr-x 1 root root    0 Mar 18 03:32 vscode-ipc-425af2fc-ddb1-4554-b93b-3a5bede4c52d.sock
srwxr-xr-x 1 root root    0 Mar 18 03:47 vscode-ipc-58739ccc-fb7d-4289-808e-21d31c703d1a.sock
srwxr-xr-x 1 root root    0 Mar 18 03:42 vscode-ipc-aa7aed50-92e4-4b2b-b17e-d70c1bba595e.sock
-rw-r--r-- 1 root root 2342 Mar 18 03:46 vscode-remote-containers-6a199ce05d20a43a350860289798f388414d648c.js
srwxr-xr-x 1 root root    0 Mar 18 03:46 vscode-remote-containers-ipc-6a199ce05d20a43a350860289798f388414d648c.sock
srwxr-xr-x 1 root root    0 Mar 18 03:46 vscode-ssh-auth-6a199ce05d20a43a350860289798f388414d648c.sock
drwxr-xr-x 2 root root 4096 Mar 18 03:46 vscode-typescript0
root@5e6a10efbea6:/tmp# 

Ceballos

Answer 1

this works:

{
    "name": "my_docker_environment",
    "dockerFile": "Dockerfile",
    "extensions": [
        "ms-vscode.cpptools",
        "twxs.cmake",
        "eamodio.gitlens",
        "ms-vscode.cmake-tools"
    ],
    "containerEnv": {
        "DISPLAY": "unix:0"
    },
    "mounts": [
        "source=/tmp/.X11-unix,target=/tmp/.X11-unix,type=bind,consistency=cached"
      ],
    "runArgs": ["--privileged"]
}

I don't recall if "runArgs": ["--privileged"] is needed but I guess no

You migth need to do

xhost local:root

on a terminal on the host before launching your app

Ceballos

Works for me as of March 2021 without ---priviliged – Phlogistic

worked for me with the newest VSCode version (1.82.2). The --privileged option isnt necessary – Norse

I get an error with this Authorization required, but no authorization protocol specified Error: Can't open display: unix:0 – Olnay

Answer 2

In order to avoid xhost +, it is possible to forward the .Xauthority with .devcontainer.json like:

{
  "image": "..."
  "runArgs": [
    "--net", "host",
    "-e", "DISPLAY=:0",
    "-e", "XAUTHORITY=/tmp/.Xauthority",
    "-v", "${localEnv:HOME}/.Xauthority:/tmp/.Xauthority"
  ]
}

Jaysonjaywalk

Answer 3

There are many different solutions on how to make x11 forwarding work with vscode on the internet. Docker 23 enabled docker buildkit as standard, some GUI applications, including openCV do not work anymore with the settings mentioned here.

Instead, on ubuntu 22.04, vscode 1.76.0 and Docker 23.0.1, the following minimal .devcontainer.json file enables GUIs including opencv for me:

{
    "containerEnv": {
        "DISPLAY": "${localEnv:DISPLAY}",
    },
    "remoteEnv": {
        "DOCKER_BUILDKIT": "0", 
    },
    "image": "YOUR_DOCKER_IMAGE",
    "runArgs": [
        "--volume=/tmp/.X11-unix:/tmp/.X11-unix",
    ]
}

Interesting reads:

• https://github.com/microsoft/vscode-remote-release/issues/1409
• https://github.com/microsoft/vscode-remote-release/issues/550#issuecomment-501293753

Chaney

Great! This works for me. In my case it was matplotlib's plt.show() getting stuck from the devcontainer while other GUIs worked from the same environment. Another detail: I didn't need to set DOCKER_BUILDKIT. – Cornela

would this work with something like playwright/cypress when using the debugger? It seems like runArgs is not supported anymore? – Ceramic

Gives me Error: Can't open display: localhost:10.0 – Olnay

Answer 4

tested on macOS, the only extra setting in devcontainer.json I used:

    "containerEnv": {
        "DISPLAY": "docker.for.mac.host.internal:0"
    },

on host machine xhost +localhost before running devcontainer

Spencerspencerian

Answer 5

If you are developing opengl applications inside a devcontainer which uses GLFW or any other windowing library, mount this as well to your container so that the FPS stays in the limit (60 by default):

    "mounts": [
        "source=/tmp/.X11-unix,target=/tmp/.X11-unix,type=bind,consistency=cached",
        "source=/dev/dri,target=/dev/dri,type=bind,consistency=cached"
    ],

I was facing these errors:

MESA: error: Failed to query drm device.
libGL error: glx: failed to create dri3 screen
libGL error: failed to load driver: iris
libGL error: failed to open /dev/dri/card0: No such file or directory
libGL error: failed to load driver: iris
Compiling Vertex Shader: DONE!
Compiling Fragment Shader: DONE!
FPS: 749
FPS: 815
FPS: 865
FPS: 898
FPS: 1834
FPS: 2528
FPS: 2448

As you can see, the FPS was blowing up because double buffering wasn't working. Mounting the /dev/dri fixed this issue and the error messages didn't show up as well.

Rabblement