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: <directfb-dev-request directfb.org>
To: <directfb-devdirectfb.org>
Sent: Thursday, March 29, 2007 9:25 PM
Subject: directfb-dev Digest, Vol 26, Issue 21
> Send directfb-dev mailing list submissions to
> directfb-devdirectfb.org
>
> 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
> directfb-dev-requestdirectfb.org
>
> You can reach the person managing the list at
> directfb-dev-ownerdirectfb.org
>
> 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 (krishna
Siddharth)
>
>
>
------------------------------------------------------------
----------
>
> Message: 1
> Date: Thu, 29 Mar 2007 05:05:38 -0700 (PDT)
> From: Daniel Laird <daniel.j.lairdnxp.com>
> Subject: Re: [directfb-dev] CreateVideoProvider by
Name
> To: directfb-devdirectfb.org
> Message-ID: <9731929.posttalk.nabble.com>
> 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
>> directfb-devdirectfb.org
>> 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/CreateVideoProvid
er-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: krishna Siddharth <krishnasiddharthtataelxsi.co.in>
> Subject: Re: [directfb-dev] TestGtkEmbed on MIPS over
DirectFB
> To: <amitw-o-i.com>
> Cc: directfb-devdirectfb.org, davidddei.net, amitrocksgmail.com,
> krishna Siddharth <krishnasiddharthtataelxsi.co.in>
> Message-ID:
> <KDELKNAFDNJOKLLOBMJICEPNCFAA.krishnasiddharthtataelxsi.co.in>
> 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:amitrocksgmail.com]
> Sent: Wednesday, March 28, 2007 5:03 AM
> To: krishna Siddharth
> Cc: davidddei.net
> 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, krishna Siddharth <krishnasiddharthtataelxsi.co.in > 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:amitrocksgmail.com]
> Sent: Tuesday, March 27, 2007 8:38 AM
> To: krishnasiddharthtataelxsi.co.in
> 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.directf
b.org/pipermail/directfb-dev/attachments/20070329/35efc914/a
ttachment.html
>
> ------------------------------
>
> _______________________________________________
> directfb-dev mailing list
> directfb-devdirectfb.org
> http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev
>
>
> End of directfb-dev Digest, Vol 26, Issue 21
> ********************************************
_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev
|
