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
