3

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]) else: 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):

screenshot

Any insights?

Improve this question
6
  • 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? Commented Jul 29, 2016 at 21:59
  • @grochmal I'm afraid it has no effect. Commented Jul 31, 2016 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. Commented Jul 31, 2016 at 1:37
  • @grochmal Perhaps. But, like I said, I tried running xvfb-run without sudo, and it had the exact same effect. Commented Jul 31, 2016 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? Commented Jul 31, 2016 at 22:01

1 Answer 1

Reset to default
1

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
7
  • 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") Commented Aug 2, 2016 at 15:17
  • Do you want to try xvfb-run -s 1920x1080x16 ./myApp? Commented Aug 2, 2016 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... Commented Aug 2, 2016 at 15:23
  • ok. As our xvfb-run are so different, can you edit your original post with your OS and version. Commented Aug 2, 2016 at 15:28
  • @mueh sure thing. Commented Aug 2, 2016 at 15:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.