Apologies, meant to send this to list, and not just Denis...
---------- Forwarded message ---------- From: James Hughes <[EMAIL PROTECTED]> Date: 2008/10/2 Subject: Re: [directfb-dev] Architecture for a DirectFB implementation for embedded co-processor To: Denis Oliver Kropp <[EMAIL PROTECTED]> Thanks for all the replies so far. I have been looking in to what may be required, but i think I need some more basic understanding of 'how things are done' Our current framebuffer driver is very cheap and cheerful - it is a virtual buffer stored on the host, that is sent (or at least the 'dirty' bits are sent) to the coprocessor, which is also the LCD interface - the host processor has no access to the actual framebuffer/LCD - it has to use the interface to the coprocessor. The coprocessor does have acceleration of various 2D graphics functions, which are obviously not used in this scheme. What I haven't yet understood correctly, is how a graphics driver works in this situation to get acceleration. I am now thinking that the above FB scheme would not work once I write a gfx driver - since there would be no way of keeping the host side virtual FB updated with changes made by the coprocessor, except by send the frame back. Slow. So how would DirectFB access the framebuffer to do any software rendering (I can see how it would do accelerated calls via the driver interface), or does the driver I provide have to have a complete set of functions to allow DFB access? Not just the accelerated ones? Or do I need to write a new framebuffer driver that talks to the coprocessor rather than memory that DFB can use for software rendering, whilst handing off accelerated calls to the coproc via the DFB driver interface? Sorry about the probably dumb questions...!!! TIA James 2008/9/25 Denis Oliver Kropp <[EMAIL PROTECTED]>: > James Hughes wrote: >> >> Hi Niels, >> >> Thanks for spending the time replying. Much appreciated. >> >> Unfortunately we don't use gcc on the copro- ARC Metaware I think. >> >> This could be the biggest stopper. Puts dev time up to months rather >> than weeks I would imagine, plus all the other work required. > > I'd go for DirectFB on the main CPU then, with just the acceleration on the > Coprocessor. > > -- > 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
