I have an app running remotely on a beaglebone, written in wxPython. I want to run the app inside of a virtual frame buffer, using Xvfb, and access it remotely using a VNC.

It may also be pertinent for you to know that I am launching VNC from inside of the application, like so:

    display = Display(":99")
    root = display.screen().root
    win_ids = [w.id for w in root.query_tree()._data['children'] if w.get_wm_name() and 'myappname' in w.get_wm_name().lower()]
    if (win_ids[0]):
       print("Found my win id. Starting x11vnc")
       system("x11vnc -quiet -sid %s -forever &" % win_ids[0])
        print("Can't find my Window ID!")

EDIT: I am using Debian Jessie with kernel version 3.8.13, and xenomai. I can't find a version number for xvfb-run or Xvfb, but I can tell you that my xorg version is 1.16.4

When I launch the app with:

    sudo xvfb-run ./myApp -s :99 -screen 0 1920x1080x16 -ac

I see the following: screenshot

However, when I launch Xvfb separately:

    Xvfb :99 -screen 0 800x600x16 -ac &

and then launch the app:

    DISPLAY=:99 ./myApp

I see this (what it should be):


Any insights?

  • You are using sudo in the first command but not in the second. Does root have the same fonts installed as the user you're running the app? i.e. did you install fonts just for the user? – grochmal Jul 29 '16 at 21:59
  • @grochmal I'm afraid it has no effect. – Fred Frey Jul 31 '16 at 1:29
  • I'm pretty confident that in sudo xvfb-run ./myApp -s :99 -screen 0 1920x1080x16 -ac the process of ./myApp ends in root's environment. Whilst in DISPLAY=:99 ./myApp the process uses the environment of the user that started it and Xorg routes the actual display to Xvfb's. Fonts are loaded before the Xorg routing. – grochmal Jul 31 '16 at 1:37
  • @grochmal Perhaps. But, like I said, I tried running xvfb-run without sudo, and it had the exact same effect. – Fred Frey Jul 31 '16 at 21:20
  • Fair enough, but what do you understand as "the same effect" (bad display or good display?). I need to say ti is pretty hard to guess what you mean by your answers (i'm not in your head). Still, after looking through xvfb-run i noticed that it runs the parameters in the order they appear. Does the same happen (bad display) if you run it as: sudo xvfb-run -s :99 -screen 0 1920x1080x16 -ac ./myApp? – grochmal Jul 31 '16 at 22:01

We clearly don't have the same version of xvfb-run, but mine is a shell script and when you run

xvfb-run ./myApp -s :99 -screen 0 1920x1080x16 -ac

no arguments at all are passed on to the Xvfb server, and all the arguments go to the application. The application has to be last on the line for options like -s 1920x1080x16 to be passed to the server. Without this the default depth of the screen in 8 bits, which might be the cause of your appearance problems.

Also, the args to pass to the server (after -s) must be made into a single sting. So finally, run:

xvfb-run -s '-screen 0 1920x1080x16' ./myApp
| improve this answer | |
  • Simply running it as xvfb-run ./myApp -s 1920x1080x16 doesn't fix it. I don't know what the xvfb-run help page says for you, but for me it says: -s ARGS --server-args=ARGS arguments (other than server number and "-nolisten tcp") to pass to the Xvfb server (default: "-screen 0 640x480x8") – Fred Frey Aug 2 '16 at 15:17
  • Do you want to try xvfb-run -s 1920x1080x16 ./myApp? – meuh Aug 2 '16 at 15:21
  • @mueh As far as I understand it, that passes "./myApp" as an arg to Xvfb, and when I tried it, xvfb-run says Xvfb failed to start. Unless I'm misunderstanding something... – Fred Frey Aug 2 '16 at 15:23
  • ok. As our xvfb-run are so different, can you edit your original post with your OS and version. – meuh Aug 2 '16 at 15:28
  • @mueh sure thing. – Fred Frey Aug 2 '16 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.