Thanks Daniel and Niels! Ok will take a look at the davinci driver. Just to make sure, if I don't use the FBdev and instead use devmem I should be good?! I guess that makes sense. I have to read the code. I'm sure I'll figure it out. :-)
I have another question though. I see that a lot of operations happen in the system memory and only some things really go into the video memory. Is that only true for fbdev or in general? I just want to make sure that whatever 2d graphic operation that can be accelerated actually is. I can see that a lot of operations are not going through the driver but through software because of CSP_SYSTEMONLY memory. -Bernd -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niels Roest Sent: Monday, November 03, 2008 11:08 AM Cc: directfb-dev@directfb.org Subject: Re: [directfb-dev] Writing a gfxdriver Hi Bernd. Considering FBdev. flipping from backbuffer to frontbuffer is done via 'panning'. The reserved FB area is, in case of double buffering, simply doubled by doubling the y-coordinate, check out dfb_fbdev_mode_to_var() in fbdev.c and look for yres_virtual. So, it is possible to offload surface memory to pools as Daniel points out, but spreading your front/back buffers across multiple pools is not possible with the current FBdev implementation, as far as I can tell. hth Niels ----------------------------------------- This message (including any attachments) may contain confidential information intended for a specific individual and purpose. If you are not the intended recipient, delete this message. If you are not the intended recipient, disclosing, copying, distributing, or taking any action based on this message is strictly prohibited. _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
