Vscode-remote-release: Display forwarding from docker container

[ilinojkovic]

How to set up remote display forwarding from Docker container?

Currently, my .devcontainer contains:

devcontainer.json

{
    "name": "kinetic_v5",
    "context": "..",
    "dockerFile": "Dockerfile",
    "workspaceFolder": "/workspace",
    "runArgs": [
        "--net", "host",
        "-e", "DISPLAY=${env:DISPLAY}",
        "-e", "QT_GRAPHICSSYSTEM=native",
        "-e", "CONTAINER_NAME=kinetic_v5",
        "-v", "/tmp/.X11-unix:/tmp/.X11-unix",
        "--device=/dev/dri:/dev/dri",
        "--name=kinetic_v5",
    ],
    "extensions": [
        "ms-python.python"
    ]
}

Dockerfile

FROM docker.is.localnet:5000/amd/official:16.04

RUN apt-get update && \
    apt-get install -y zsh \
    fonts-powerline \
    locales \
    # set up locale
    && locale-gen en_US.UTF-8

RUN pip install Cython

# run the installation script  
RUN wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | zsh || true

CMD ["zsh"]

This doesn't seem to do the job.

Setup details:

• OS: linux
• Product: Visual Studio Code - Insiders
• Product Version: 1.35.0-insider
• Language: en

I already asked this on stackoverflow, but no response there.

[chrmarti]

For which application do you want to forward the display? How do you start it?

[ilinojkovic]

I'm running a mujoco simulation inside a docker container, and in some cases would like to visualize the simulation. I'm using the official c++ api which uses glfw to create the window.

[chrmarti]

This seems to be an issue independent of VS Code's Remote Containers. Do you have this working just with Docker?

[ilinojkovic]

Yes. I used this script which worked fine:

#!/bin/bash
xhost +local:
VERSION=$"3"
docker run -it --net=host \
  -u=$(id -u) \
  -e DISPLAY=$DISPLAY \
  -e QT_GRAPHICSSYSTEM=native \
  -e CONTAINER_NAME=kinetic_v${VERSION} \
  -e USER=$USER \
  --workdir=/absolute_path_to/workspace \
  -v "/tmp/.X11-unix:/tmp/.X11-unix" \
  -v "/etc/group:/etc/group:ro" \
  -v "/etc/passwd:/etc/passwd:ro" \
  -v "/etc/shadow:/etc/shadow:ro" \
  -v "/etc/sudoers.d:/etc/sudoers.d:ro" \
  -v "/home/$USER/:/home/$USER/" \
  --device=/dev/dri:/dev/dri \
  --name=kinetic_v${VERSION} \
  ilinojkovic/ros:kinetic_v${VERSION}

When I move all these arguments into runArgs, I cannot get it to connect/bind the display.

[ishouldbedany]

Hi. Code user here in a similar situation.

I followed up with @ilinojkovic via email and we reached the conclusion that X11 forwarding works with the following runArgs in .devcontainer.json:

"runArgs": [
        "--net", "host", 
        "-e", "DISPLAY=${env:DISPLAY}",
        "-v", "/tmp/.X11-unix:/tmp/.X11-unix"
],

Some of the lines in his original setup were messing things up. As extra info, I am logging as a root user (at least in my case).

Regardless of this having worked, I think it would be positive to add some documentation on how to achieve this and/or ease the workflow.

For image/video applications (think OpenCV, VTK, PCL, Kinect, ROS, etc, which are all dependency hell) or even basic Data Science environments (interactive matplotlib plots, for instance - I know the Jupyter cell mode exists in VS Code, but interactivity there is essential), having access to the native windows is critical.

I image that as VS Code Remote gets more popular and some of these complex frameworks start to consider offering its development environments through containers, this request will become increasingly popular.

Also taking the opportunity to thank you for an incredible piece of software. It's stellar! :+1: :+1:

[chrmarti]

Great, thanks @ishouldbedany @ilinojkovic !

@Chuxel Is X11 forwarding something you would want to include in our documentation? (See above comment.)

[Chuxel]

@chrmarti Yeah #616 is the same doc suggestion and I got it working both on Windows (via VcXsrv) and macOS - it uses a slightly different model that works for Windows too. I can take the to-do to doc it.

[ilinojkovic]

Just as a follow up, the issue was solved with the modification from @ishouldbedany's comment, but then reappeared. In the meantime, I updated os packages and vs-code itself, so I don't know if that's somehow connected. I rebuilt the image, but the error persisted.

[ishouldbedany]

I have a fully updated Ubuntu 18.04 LTS as a host and VS Code 1.35.1. Working normally for me.

[ishouldbedany]

Update: I'm having the same issue in one of the containers I have with X-forwarding enabled. On another one I have, everything is working normally (with the same configuration).

I also did some minor OS upgrades, but nothing major, it came very out of the blue. I also rebuilt the image, no luck.

I am not sure what's causing this and my knowledge of the Linux desktop stack is limited at best. Happy to provide further info and help debugging.

[ishouldbedany]

Update on my update: I manged to get it working again by running, on the host system, the command at the start of @ilinojkovic's initial script:

xhost +local:

The solution (with some follow-up discussions on security) is available here: https://github.com/jessfraz/dockerfiles/issues/6

This instruction seems to be reset everytime the X server is restarted, hence why this method is working intermittently.

[Chuxel]

Just to update the thread, the reason this hasn't been added to docs yet is it is a bit tricky to get working particularly on macOS. We looked at doing this for Microsoft/vscode, but held off because of these issues. More details here:

https://github.com/microsoft/vscode/issues/82060#issuecomment-542431498

It all works, but I'm less confident in documenting it as a "supported scenario" at the moment. UI perf was also pretty bad, but part of that may be due to the lack of access to GPU acceleration on Windows/macOS.