8

I prepared Dockerfile to build Docker image of my Qt application. To run the application I use X - I enable access to X server (xhost +local:root), then I use the following command to run it:

docker run -it --env="DISPLAY" --env="QT_X11_NO_MITSHM=1" \
    --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" mindforger:latest mindforger

The problem is that some Qt UI elements (menu items, dialogs, ...) are rendered blank in black (randomly) - check the screenshot below:

enter image description here

I'm on Ubuntu 16.04.5 with Docker 18.06 and Qt 5.01.

Martin Dvorak
  • 790
  • 8
  • 15
  • Hi @martin-dvorak, do you have been able to solve the problem? I'm really interested in the issue. Any workaround will be of utility. – Rama May 08 '19 at 00:35
  • @Rama unfortunately I wasn't able to find neither workaround nor solution. If you find any, please let me know as well. – Martin Dvorak May 10 '19 at 04:09
  • 1
    But... why? Why docker? Anyway. Do other applications show normally? Like some standard `Gnome/KDE` apps. I strongly recommend using something newer than Qt 5.0.1. It was an extremely buggy release. And it's super old. – Sirajo Abubaka Zauro May 11 '19 at 08:55

5 Answers5

3

I had the same problem, and I couldn't solve it formally. But we found an alternative workaround to not display the error:

In our case, we have four QComboBoxes in a window. Our problem was that after starting the app, the second (sometimes the first) combo box you clicked displayed a black popup. So what we did was initializing the window with two dummy combo boxes, calling the showPopup method, and then hiding both the popups and the combo boxes. So the user can't notice the error. I hope you can make something similar with your app.

maxi.marufo
  • 411
  • 2
  • 11
1

I had the same problem and found this solution which you have to run after starting the docker container. Once the specific docker container is started, run the following command within the docker container.

export QT_GRAPHICSSYSTEM="native"

Once this is pasted and executed within the docker terminal session, run the desired QT application and this black box problem should go away. You could even paste this option inside your docker's .bashrc if you didn't want to run it every time manually.

tardis89
  • 53
  • 7
1

None of the posted solutions solved the identical problem that I encountered. However, this did fix it: QT_GRAPHICSSYSTEM=raster

Mike
  • 11
  • 1
  • Never mind. That just seems to push the problem around a bit. It is non-deterministic. Hits some pulldowns, but not others, and varies by application instance. – Mike Jun 07 '20 at 19:29
0

In my case (Qt5 application) I resolved this by adding the param --shm-size 128M, mounting /dev/shm:/dev/shm should work too.

Andrew Mackrodt
  • 1,806
  • 14
  • 10
0

I ran into this problem trying to get Google Earth Pro to work in Docker -- several dialog boxes and a few menus would be black-on-black or random pixels.

That specific graphics issue was solved by adding --ipc host to the create (or run) command.

Here is the distilled create command that I used; I didn't have to disable or configure shm (and none of the shm suggestions I tried helped):

docker create \
  --ipc host \
  -e DISPLAY -e XAUTHORITY \
  -h "$HOSTNAME" \
  -u "$(id -u):$(id -g)" \
  --device /dev/dri/card0 \
  -v /dev/dri/card0:/dev/dri/card0 \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -v "$XAUTHORITY:$XAUTHORITY" \
  my-qt-app

A small break-down:

  • --ipc host - This is what fixed the "black menus/dialogs"
  • -v "$XAUTHORITY:$XAUTHORITY", -v /tmp/.X11-unix:/tmp/.X11-unix and -e XAUTHORITY/-e DISPLAY is required or the app doesn't launch and complains about not finding a display server and complete failure without the -v $XAUTHORITY:XAUTHORITY
  • -v /dev/card0:/dev/card0 (in my script, I find those somewhat naively using findfind /dev/dri -maxdepth 1 -type c) is required to avoid Mesa errors, however, the application still works (poorly).
  • -u ... My implementation "hides" docker from the user, so it creates the container as the user, sets it up with a containerized "fake" version of their user account and uses it to launch the app, which the docker container is configured to use when it runs it. ...avoiding root GUI apps.
mdip
  • 600
  • 4
  • 10