Native C *GRAPHICAL* applications now working on Android emulator

67 views
Skip to first unread message

TomCooksey

unread,
Nov 14, 2007, 2:57:47 PM11/14/07
to Android Developers
I've just realized there's a standard Linux framebuffer device: /dev/
graphics/fb0. You can write to it in the usual way. This means that
phones supporting the Android platform may be able to run other GUI
phone stacks such as Qtopia, Maemo or OpenMoko - Should anyone feel
the need! :-)

Here's a quick program to demonstrate this by flashing the screen
every second (I know, ultra-high tech stuff this!). If you want to try
it out, you'll need to get yourself a cross compiler, compile the
following program, copy it to the android emulator & run it (Search
this group for instructions). For some reason it can take a while
before the screen starts flashing... dunno why. :-p

Note: This is _not_ using the Android surface manager - that's going
to take a lot more work (my hat goes off to the first person to do
it!)

----------------------------------------------------------

#include <stdio.h>
#include <sys/mman.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>

#define PIXEL_COUNT (320*240)

unsigned short* fb = NULL;

int main(int argc, char** argv)
{
int fb_fd;

do {
fb_fd = open("/dev/graphics/fb0", O_RDWR);
if (fb_fd == -1)
{
printf("Error opening framebuffer: %s\n", strerror(errno));
break;
}

fb = (unsigned short*) mmap(0, PIXEL_COUNT*sizeof(unsigned
short), PROT_WRITE, MAP_SHARED, fb_fd, 0);
if (fb == MAP_FAILED)
{
printf("Error mmap'ing the framebuffer: %s\n",
strerror(errno));
break;
}

do {
memset(fb, 0, PIXEL_COUNT*sizeof(unsigned short));
sleep(1);
memset(fb, 0xFF, PIXEL_COUNT*sizeof(unsigned short));
sleep(1);
} while (1);

} while (0);
return 0;
}

David Lecomte

unread,
Nov 14, 2007, 3:38:08 PM11/14/07
to Android Developers
In /system/lib, there are a bunch of libraries and among them :
libopengles_cm.so.
Using nm, it seems this library contains EGL so the only thing we need
is to be able to link with this lib.

David

Patrick McKinnon

unread,
Nov 14, 2007, 3:54:03 PM11/14/07
to Android Developers
Hey David,

What version of the cross compiler are you using? I tried with arm-
none-linux-gnueabi-nm from codesourcery but I get "no symbols" (same
thing when I tried to link against their libc).

I can however see everything with:

arm-none-linux-gnueabi-strings libopengles_cm.so | c++filt

Also, there is some interesting stuff in libui.so

Thanks,

-Patrick

TomCooksey

unread,
Nov 14, 2007, 4:17:48 PM11/14/07
to Android Developers
> In /system/lib, there are a bunch of libraries and among them :
> libopengles_cm.so.
> Using nm, it seems this library contains EGL so the only thing we need
> is to be able to link with this lib.

This will work for giving us access to 3D, but I'm pretty sure this
wont allow us to talk to the surface manager. I suspect the surface
manager will be using that library for compositing application
windows. If it's like the other OpenGL ES implementations I've come
across, it wont allow pbuffers to be shared across process boundaries.
Assuming this is the case, it means that the surface manager either:

a) Does all the rendering itself, possibly exposing rmi methods to
create windows/render stuff/etc to other processes
b) Each process does software rendering into a shared memory segment
which the surface manager composites onto the screen
c) Each process renders into a pbuffer which is also a shared memory
segment which gets composited.
d) Does something clever.

Given that this is a cut down version of the java runtime for embedded
devices, rmi seems unlikely, ruling out (a). Given that applications
can render in 3D, I'm thinking b) isn't an option either. (c) is a
hack, probably wouldn't work and thus also not likely... so I think
they are doing something clever. Either that or each process renders
into a pbuffer and the EGL implementation is clever enough to allow
the surface manager to access pbuffers from different processes and
composite them together.

That is assuming the surface manager is running in a separate
process... looking at a ps output, nothing strikes me as "this is the
surface manager process". Hmmmm.

I'm working on linking to the Android libraries now, although taking
the LoadLibrary() route with static linked executables at this point.


David Lecomte

unread,
Nov 14, 2007, 6:00:05 PM11/14/07
to Android Developers
I used :
arm-none-linux-gnueabi-nm -D libopengles_cm.so

David

On Nov 14, 12:54 pm, Patrick McKinnon <patrickmckin...@gmail.com>
wrote:

Patrick McKinnon

unread,
Nov 14, 2007, 6:09:53 PM11/14/07
to Android Developers
Oops, duh I'm a retard... Thanks David.
Reply all
Reply to author
Forward
0 new messages