I can't provide more information because of the NDA with our manufacturer. But the .so does more. (seen with strace) It creates a shared memory with a daemon (also proprietary) and there also goes some information between them. But we seen some mmap's to a device which was our victim here. But we need the rest of the original daemon for initialisation and after it is initialized we wrote a 'libgralloc' which now works nicely.
The next step is to implement double buffering. But is has no priority since we have display and we see DalvikVM segfaulting.. Propably something with memory. But I will open another thread for that.. Our solution is that we wrote another application which is build on the other libc of our manufacturer. with this application we perform initialisation and we provide screen information back to the surface flinger through an net socket. (IPC is not supported with Android libc) After the initialisation we open the device node directly and we write directly to that buffer which gives us what we want. When the gralloc library is completely finished perhaps we may publish it here to use it as further reference. Regards, Rik van der Heijden On 4 apr, 21:46, Nicola La Gloria <[email protected]> wrote: > Could you provide the chip manufacturer or some other specification? > What kind of chip is it? > I think that, as strange the system (and proprietary) is, it will > always connect to a device thru a file descriptor created by the .so > lib (if not by the kernel). > Is it a kind of frame buffer (may be not)? > Only then you could be able to know where modify the surfaceflinger. > The only documentation are the lists and the code. > > Regards > > Nik > > On Mar 25, 2:50 am, Rik vd Heijden <[email protected]> > wrote: > > > We have the biggest part of our system working. But our system doesn't > > provide /dev/fb* or /dev/graphics/* > > The manufacturer of our chip made a userspace daemon and an .so file to > > interface with the display (which are not open-source). And this .so-file is > > linked to a different version of libc then the android libc. > > When Android tries to load the .so-file the surfaceflinger crashes and > > logcat shows a relocation-error with the libc's. > > So we think we must make a modification to Android in order to change the > > the way android interfaces with the display to this system. > > > Our question is, what exactly do we need to change in Android in order to > > get Android to interface to the .so file then to the framebuffer. > > > The platform is ported before by other OEM's, but we don't have a source of > > it. -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
