Hi Ilyes, > DirectFB's design so far (albeit extendable) is to have surface allocations > managed by the system module's surface's pool manager. The default manager > assumes a mmap()'ed framebuffer memory from which it will reserve the > surface's buffers. So this is all done in user-space (unlike kernel's drm).
Interesting, I've only used DFB with our custom IntelCE systems driver, which only exposes video memory based surfaces as physically contiguous. I had always assumed fbdev was only mapping physically contiguous memory also. > In my use-case I needed a way to allocate a contiguous buffer, load it up > w/ compressed data, and then send it to a v4l2 device for a decode. That > same v4l2 device will also write into a DirectFB destination surface, then > blitted for display. Understood. > A8 is an alpha surface, a mask. A BYTE surface would be carrying an > *opaque* payload. Technically yes, but it's just a description (aside from the macros setting how many bits are for alpha, R, G and B). I've seen this approach used before to do textured video in OpenGL ES 2.0 when the YUV 4:2:0 data was in a pseudo-planar NV16 format and the OpenGL ES implementation didn't handle any YUV formats, as a way to provide the Y and UV buffers to the shaders to render. > One distinction is the modified dfb_gfxcard_calc_buffer_size() that ignores > any padding applied by the CardLimitations::surface_bytepitch_alignment and > CardLimitations::surface_pixelpitch_alignment. > > To make it more interesting, we could add concepts such as meta-data attached > to the surface that's only accessible to the system/acceleration modules and > so > on, but where DirectFB core is just a pass-through. Surface meta-data is a nice extensible concept. :) > It could still be a 'special' surface: a single-buffered, video only, (a > CSTF_BUFFEROBJECT) surface. It could carry compressed data, a list of > vertices, > etc. Okay, I haven't explored CSTF_BUFFEROBJECT usage before (another engineer on my team handles the newer DFB 1.6 activities). It such an approach gains traction, it would be good if such objects had a capability flag to indicate that they didn't contain pixels so that could be queried and the unsuitable surface functionality would fail if attempted, prevent sub-surfaces from being created, and so on. Best Regards, Timothy -- Timothy Strelchun STB & SW Engineering PCCG Service Provider Division Intel Corporation _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
