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
#define PIXEL_COUNT (320*240)
unsigned short* fb = NULL;
int main(int argc, char** argv)
fb_fd = open("/dev/graphics/fb0", O_RDWR);
if (fb_fd == -1)
printf("Error opening framebuffer: %s\n", strerror(errno));
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",
memset(fb, 0, PIXEL_COUNT*sizeof(unsigned short));
memset(fb, 0xFF, PIXEL_COUNT*sizeof(unsigned short));
} while (1);
} while (0);
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
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.
On Nov 14, 12:54 pm, Patrick McKinnon <patrickmckin...@gmail.com>