Beagleboard XM with VNC server

Hello,

My question is regarding VNC server setup on the Beagleboard XM rev. C.

I am running Android, and a VNC server on my Beagle. On my host machine I am
running a VNC viewer. But on the host VNC viewer, all I see is the green Android
"robot" that comes up at the very beginning (right after bootup).

However on the DVI output of the Beagle I do see all the good Android stuff -- the home
screen, the movable cursor, widgets, etc.

It is as if the VNC server is showing a framebuffer that is not getting the
Android screen info written to it.

Here are some (possibly) relevant kernel command line parameters I am using:
  vram=8M
  omapfb.vram=0:8M
  omapfb.mode=dvi:1024x768MR-16@60
  omapdss.def_disp=dvi

From the strace output, I am pretty sure the VNC server is using /dev/graphics/fb0.
It is interesting that this framebuffer still contains the green android logo from
the early boot stage, while the DVI output shows a full-up working Android display.

Can anyone provide any insight as to how I can get the full Android display out over
the VNC session?

I can provide more info if needed.
Thanks very much,
Chuck

Hello,

My question is regarding VNC server setup on the Beagleboard XM rev. C.

I am running Android, and a VNC server on my Beagle. On my host machine I am
running a VNC viewer. But on the host VNC viewer, all I see is the green Android
“robot” that comes up at the very beginning (right after bootup).

However on the DVI output of the Beagle I do see all the good Android stuff – the home
screen, the movable cursor, widgets, etc.

It is as if the VNC server is showing a framebuffer that is not getting the
Android screen info written to it.

Here are some (possibly) relevant kernel command line parameters I am using:
vram=8M
omapfb.vram=0:8M
omapfb.mode=dvi:1024x768MR-16@60
omapdss.def_disp=dvi

From the strace output, I am pretty sure the VNC server is using /dev/graphics/fb0.
It is interesting that this framebuffer still contains the green android logo from
the early boot stage, while the DVI output shows a full-up working Android display.

Can anyone provide any insight as to how I can get the full Android display out over
the VNC session?

I don’t have any personal insight yet, but I did discuss with Mike Anderson of The PTR Group yesterday at ESC Boston that he has a setup where he’s running a VNC server on a BeagleBoard-xM in Android. When I hear back some details, I’ll be sure to share.

Hi Jason,

I work at The PTR Group with Mike. Actually he is referring to the VNC server that I got working
since we last spoke. It is a particular VNC server from . That VNC server was by far the most robust that I tried out. It has a great feature of being able to take the keyboard and mouse actions that it receives from the VNC client/viewer, and pump them into /dev/uinput. The /dev/uinput device allows userspace code to inject input actions as if there was a local touchpad/keypad. You do have to reconfigure and rebuild the Linux kernel with UINPUT support. So on a bare BeagleBoard-XM with no mouse, keyboard, nor display physically attached, I am able to do a full Android interface through VNC. One thing to point out that took a while to find – you do need to specify the vram and omapfb.vram parameters very carefully. The VNC server will send out the display info from the beginning of the framebuffer device, and the Android 2.3.4 that I have running will use the last available portion of that framebuffer device. So if you specify the framebuffer too large, the VNC server is not sending the display info you expect. The formula for those sizes is your resolution * bytes per pixel * 2 (Android double-buffers). So for 640x480 at 16bpp, the calculation is 640 * 480 * 2 * 2. Make the framebuffer and the vram sizes equal to that, and the VNC server works fine. There is a glitch in the VNC server where it does not always seem to track the double-buffering, so you sometimes have to click the screen to get it synced to the buffer that should be displayed. But that is a minor thing. Chuck