Hi Timothy, 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). 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.
On Thu, Nov 8, 2012 at 9:57 PM, Strelchun, Timothy < timothy.strelc...@intel.com> wrote: > Hi Ilyes, > > A video only surface (typically external) already is a physically > contiguous memory buffer (normally/always AFAIK), and there already is the > pixel format DSPF_A8 which is one byte that could be repurposed. A8 is an alpha surface, a mask. A BYTE surface would be carrying an *opaque* payload. 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. So, I don't understand the need to create a new surface pixel format for a > surface buffer that is NOT a surface 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. > especially since the surface interface allows pixel based operations to be > performed on it (blitting and drawing) and it can be flipped (allocation > can be double/triple buffered). > > These can be toggled on/off by checking on the surface's pixel format, caps, etc. I agree it looks like a hack. Best regards, -Ilyes > Best Regards, > Timothy > > -- > > Timothy Strelchun > STB & SW Engineering > PCCG Service Provider Division > Intel Corporation > > >-----Original Message----- > >From: directfb-dev-boun...@directfb.org [mailto:directfb-dev- > >boun...@directfb.org] On Behalf Of Ilyes GOUTA > >Sent: Wednesday, November 07, 2012 3:33 AM > >To: directfb-dev@directfb.org > >Subject: [directfb-dev] [PATCH] directfb: introduce the new DSPF_BYTE > >opaque pixel format > > > >Hi, > > > >The attached patch defines a new DSPF_BYTE pixelformat allowing > >DirectFB-based applications to allocate IDirectFBSurface(s) which are > >backed by contiguous buffers in physical memory. These surfaces could > >be used for transport such by loading data into these and passing them > >to other devices (ex: h/w decoders). > > > >As these are still IDirectFBSurface(s) objects, DSPF_BYTE surfaces > >then also benefit from all the internal functionality provided by > >DirectFB such as reference counting, the integration w/ > >IDirectFBDataBuffer and so on. > > > >Feedback is welcome. > > > >Regards, > >-Ilyes > _______________________________________________ > directfb-dev mailing list > directfb-dev@directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >
_______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
