Yes I know the change is in sorry. Hopefully we can resolve that issue first before this gets committed.
As far as multi-app goes I have to have a real file handle ? I never found out what SHARED| ANON actually means. Finally found a thread on it :) http://mail.nl.linux.org/linux-mm/1999-01/msg00034.html That was a hidden test question :) So we have three cases I think. 1.) Preallocated memory user beware if its shareable between processes. 2.) A file in tmp to allocate real shared memory. 3.) Driver Allocated but private memory. And later people may want to add more like a surface pool. So should I just handle the first two cases. If its pre allocated then in join we just use the address passed in. I think I need another variable to handle deciding on 2 or 3. This could be extended later to also do a pool ? So something like. video-allocate=shared ? On Dec 5, 2007 1:13 AM, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel wrote: > > Attached is the new ram only system. > > In primaryFlipRegion() could should call dfb_surface_flip() at least. > > I don't think the multi application core will run. Each process will > allocate its own chunk of memory, though at the same virtual address. > > You need a file in tmpfs. Or is there a way to share anonymous memory? > > BTW, your lock change is also in the patch. > > -- > > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
