I tried to change pool.c and heap.c to alloc memory heap from another device(/dev/cmem), not shared mem of tmpfs. /dev/cmem is a device driver, which can be used to alloc physical-contious memory. and can also be shared by muti-proceess.but I have trouble is that DFB crashed. my question is, can it work if I change tmpfs to cmem, can I do it?? anybody can help me?
----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, March 29, 2007 9:25 PM Subject: directfb-dev Digest, Vol 26, Issue 21 > Send directfb-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of directfb-dev digest..." > > > Today's Topics: > > 1. Re: CreateVideoProvider by Name (Daniel Laird) > 2. Re: TestGtkEmbed on MIPS over DirectFB (Kumar Siddharth) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Mar 2007 05:05:38 -0700 (PDT) > From: Daniel Laird <[EMAIL PROTECTED]> > Subject: Re: [directfb-dev] CreateVideoProvider by Name > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > > Denis Oliver Kropp wrote: >> >> Daniel Laird schrieb: >>> I was wondering what people thought about adding a >>> IDirectFB_CreateVideoProviderByName function: >>> >>> this would have a prototype like: >>> IDirectFB_CreateVideoProviderByName( >>> IDirectFB *thiz, >>> const char* filename, >>> const char* videoprovidername, >>> IDirectFBVideoProvider **interface) >> >> Some explicit implementation selection should be there, not only for >> video providers. >> >>> The reason for this is that if you have a number of VideoProviders >>> calling >>> Probe on each in turn can be time consuming and also requires data to be >>> going through the system. >>> If you could shortcut this by specifying a name which could be the >>> VideoProviderName without lib or .so then this would allow a quick way of >>> saying - I know I am getting AVI data and I know which VideoProvider I >>> need. >> >> It's also necessary to select between different suitable implementations. >> >>> The only problem is that CreateVideoProvider uses a common function >>> DirectGetInterface and this change does not appear to fit easily with the >>> current implementation. >>> >>> I am a bit confused by the 'implementation' parameter to the >>> DirectGetInterface function, is this maybe what i should use to implement >>> the IDirectFB_CreateVideoProviderByName function? >> >> Yes. The "implementation" is e.g. "ffmpeg" or "hw264". >> >> -- >> Best regards, >> Denis Oliver Kropp >> >> .------------------------------------------. >> | DirectFB - Hardware accelerated graphics | >> | http://www.directfb.org/ | >> "------------------------------------------" >> >> _______________________________________________ >> directfb-dev mailing list >> [email protected] >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> >> > > Currently in the DirectGetInterface function it checks against the > implementations and if not found tries dynamically loading each interface in > turn and seeing if the probe succeeds. > I would still need to have dynamic loading of interfaces but allow me to > specify an exact library rather than the current usage which is every one > within a given directory. > > So I am still confused as to how I would add this functionality. But have an > idea - > > Currently if you have an implementation it tries to load it > If you specify a type and no implementation it loads all libraries > dynamically until probe succeeds > > Perhaps I could add logic that says if you define both implementation AND > type that it just loads the given implementation of a certain type > dynamically > The code would be put in between the current > /*Check Implementations first*/ > And > The DYNAMIC LINKING section. > > I think this would work, what do you think? > > Cheers > Dan > > -- > View this message in context: > http://www.nabble.com/CreateVideoProvider-by-Name-tf3478829.html#a9731929 > Sent from the DirectFB Dev mailing list archive at Nabble.com. > > > > > ------------------------------ > > Message: 2 > Date: Thu, 29 Mar 2007 18:57:03 +0530 > From: Kumar Siddharth <[EMAIL PROTECTED]> > Subject: Re: [directfb-dev] TestGtkEmbed on MIPS over DirectFB > To: <[EMAIL PROTECTED]> > Cc: [email protected], [EMAIL PROTECTED], [EMAIL PROTECTED], > Kumar Siddharth <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > > Hi Amit, > > I think you missed one more important thing. You have mentioned that you are > using GTK 2.10.3, but the Firefox on DFB patch that we have released is for > GTK 2.10.1. Also, we were having display problems with Mozilla if we used > anything other than GTK 2.10.1 . There is a strong version dependency. > > What I suggest is: just go through Bugzilla and DFBMozilla wiki page for > build instruction and version information, and build Mozilla with GTK 2.10.1 > . You should get correct output as we are getting it on ARM. Please note > that you will get a patch for GTK also apart from Firefox. Apply that patch > to your GTK code. > > Yeah we do get Colormap assertion as the problem is with the GTK 2.10.1 and > was fixed in later versions. But it does not affect the output. > > You can also post your DFB related queries to "directfb-dev" mailing list > for expert comments. > > Hope it helps you. > > Regards, > Siddharth > TATA Elxsi, India > > -----Original Message----- > From: amit shah [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 28, 2007 5:03 AM > To: Kumar Siddharth > Cc: [EMAIL PROTECTED] > Subject: Re: TestGtkEmbed on MIPs over DirectFB > > > Hi Siddharth, > > One important piece of information I missed yesterday on my mail was > > Whenever the browser tries to paint on the screen we see this message on > the console. > > (TestGtkEmbed:20853): Gdk-CRITICAL **: gdk_drawable_set_colormap: > assertion `cmap == NULL || gdk_drawable_get_depth (drawable) == > cmap->visual->depth' failed > > This we verified by displaying an animated GIF on the screen only the > first frame is seen and the browser starts to spew the above mentioned > message as it tries to paint the next successive frames. > While the browser is spewing out these messages if i reload the page I > see the last GIF frame rendered which is may not be the same as the first > one . > > Are we missing something here. > > regards > --amit > > Replies to your queries below. > > > On 3/27/07, Kumar Siddharth <[EMAIL PROTECTED] > wrote: > Hi Amit, > > I have tested the stripped down version of TestGtkEmbed(provided by you) > with our Firefox X86 build over DFB and it is working fine. Also, we are > able to run our Mozilla TestGtkEmbed over DirectFB on ARM processor. It is > rendering local pages quite well. May be the problem lies somewhere else. > > What is your target OS..?? > > We are using open embedded linux with kernel version > 2.6.11-r000069-V1.08rc9 > > > > Are DirectFB examples running fine..?? > > Yes all of the examples are running fine except the following ones > 1) df_flip : Fills the screen with gray colour : attachment = > df_flip.cap > 2) pss :Bombed : attachment = pss.cap > 3) df_drivertest : Got stuck on initialization : attachment = > df_drivertest.cap > 4) df_texture :Bombed : attachment = df_texture.cap > > I have also included the o/p of df_ok which is some benchmarking info > which might be helpful. > > > > > > Are you able to run GTK Demos properly..?? > > Yes they run fine > > > > Is it something to do with the memory available etc..(Just a wild > guess)..?? > > > Memory status before running TestGTkEmbed > 1K blocks > Total Used > free Shared buffers > 93284 59668 > 33416 0 2288 > Memory status AFTER running TestGTkEmbed > 93284 68724 > 24560 0 2288 > > > > > Just to inform you, we have fixed some bugs related to transparent > images and gifs. We'll be releasing the patch shortly. That may be of some > help for you. > > From which folder you are running TestGtkEmbed..?? Try running from > mozilla/dist/bin . > > Tried it. Same results. > > > > Regards, > Siddharth > TATA Elxsi, India > > > -----Original Message----- > From: amit shah [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 27, 2007 8:38 AM > To: [EMAIL PROTECTED] > Subject: TestGtkEmbed on MIPs over DirectFB > > > Hi Siddhrath, > > We are trying to port over firefox on a mips based AMD > au1200 processor. We have reached a stage where we can build the complete > browser reliably. > > However, when running the TestGtkEmbed and TestGtkEmbedNotebook (in > mozilla/embedding/browser/gtk/tests/), we are having a problem with > refreshing the screen. Actually, with the notebook program, nothing draws. > With the TestGtkEmbed (stripped down version attached) it displays the > initial screen upon loading the url, but then nothing after unless we reload > the document. Obviously, this affects things like java script with timers > and active objects as well as animated gifs (we only see the first image). > > The stripped down TestGtkEmbed program has only the toolbar and > status bar left. The toolbar at the top and status bar at the bottom. If I > remove any more of the draw events for any of the other objects, then even > the initial screen for the browser will not draw. However, we are seeing > both the tool bar and status bar updating fine. > > It appears to be something to do with a signal from the browser > object rendering to not triggering the redraw of the screen. However, all > attempts to use the obvious Gtk/Gdk calls to force refresh such as show, > draw, invalidate, etc. (hooked to the js_status callback among other places) > have no affect. > > Could you please let me know the best way to approach debugging this > problem? What are the best places to put debugging to isolate it? Is one of > the 'qa' test programs appropriate to help isolate this problem? > > I have included the list of distributions we used below. Any help you > could provide would be very much appreciated. > > thanks > --amit > > > atk-1.9.0 > binutils-2.16.1 > xpgot patch > cairo-1.2.4 > DirectFB-1.0.0-rc2 > fontconfig-2.4.1 > freetype-2.1.10 > gcc-3.4.4 > Backported gcc 4.0 visibility flag > MABI 32 support for MIPS > gdb-6.5 > glib-2.12.3 > glibc-2.3.6 > gtk+-2.10.3 > jpeg-6b > libIDL-0.8.7 > libpng-1.2.12 > libxml2-2.6.23 > linux-libc-headers-2.6.11.0 > linuxthreads > linuxthreads_db > ncurses-5.5 > pango-1.14.4 > pkg-config-0.21 > SDL-1.2.11 > SDL_gfx-2.0.13 > termcap-1.3.1 > zlib-1.2.3 > firefox 1.5.0.3 > with DFB patch > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.directfb.org/pipermail/directfb-dev/attachments/20070329/35efc914/attachment.html > > > ------------------------------ > > _______________________________________________ > directfb-dev mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > End of directfb-dev Digest, Vol 26, Issue 21 > ******************************************** _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
