Ok, Yes we use the 2d accel module - (same 2d block on both chips)
I am using devmem for all osd,offscreen etc. I will try getting the virtual surface thing to work again for vid layers however. simply set lock.addr to NULL - I understand or at least allocate on dummy line - Not sure what this means sorry. and set lock.pitch - ok I understand this bit Once I get this to work I can hopefully push us to bounce from DFB1.0 -> 1.2 which should bring various benefits. Cheers Daniel Laird -------------------------------------------------- From: "Denis Oliver Kropp" <[EMAIL PROTECTED]> Sent: Friday, July 25, 2008 5:19 PM To: <[EMAIL PROTECTED]> Cc: <directfb-dev@directfb.org> Subject: Re: [directfb-dev] Virtual Surfaces for Video Layers in gfxdrivers > Daniel Laird wrote: >> On STB810 (pnx8950 based) and STB225 DFB1.0 we used virtual surfaces. >> These had no associated memory but reported sizes etc and this was done >> by >> using the allocate surface function for video layers: >> >> dfb_surface_create_preallocated(core, config->width, config->height, >> config->format, CSP_SYSTEMONLY, >> Caps, NULL, NULL, NULL, 0, 0, >> ret_surface); >> >> This AFAIK meant we had a surface but no memory attached. >> >> This allowed us to call GetSurface on a VideoLayer and then we used the >> surface handle >> to look up what video layer we really meant and make sure our decoder >> output to that layer. >> Also solved issues where our HW always has layer 0 = video. Whereas DFB >> has Primary FB layer as 0 >> >> I am now trying to move to DFB1.2 and did not like V1 of my DFB1.0 driver >> as it relied on FBDev system. >> So I used your rather nice davinci driver as a basis. >> This also will make it Open and more supportable in the future. > > Great! > > Are you going to use devmem for the OSD and offscreen surfaces? > > I guess you're at least keeping the kernel module for acceleration. > >> However I now want to handle virtual surfaces and this is a difference to >> the davinci. > > Well, you can still do the same and simply set lock.addr to NULL or at > least allocate on dummy line > and set lock.pitch to 0 :) > >> I am happy passing a NULL surface to PlayTo but I have no way of getting >> the Source etc as you indicated above. This means I have >> no easy way of specifiying which of the 2 video layers I am rendering to. >> I could hack the ctx parameter but this is a dirty hack. > > True, the virtual surface is a nicer solution, at least for DirectFB > 1.x... > >> Should PlayTo be modified to take either a surface or a Layer? > > I'm planning to change the API anyhow, moving away from the strong > layer-surface binding, > allowing to call something like IDirectFBDisplayLayer::SetSurface() or > even more advanced. > > This will also allow showing one surface on different layers, > allowing different positioning and scaling on different screens. > >> Could we move CreateVideoProvider from top level interface to >> Surface/Layer so that either can create a VideoProvider. >> i.e DisplayLayer->CreateVideoProvider and Surface->CreateVideoProvider. >> The Video Provider could then be passed the 'parent' creator in the >> Construct call and then we would be able to handle both Layer or Surface. >> >> I am looking for some advice and am happy to try things out as we try to >> make a better version of the DFB1.2 driver. > > Let's keep the virtual surfaces with 1.2 and do heavier changes in 1.3 > (->1.4) or better in 1.5 (->2.0). > > Those changes would better match the virtual surfaces anyhow :) > > -- > 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 > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
