Jason BARSTOW wrote: > > > > I am pursuing my research into directFB - I have some questions: > > Q. Is there any examples of providing DLCAPS_WINDOWS ? > My understanding is that normally dfb will render down all windows' > surfaces to the layer's surface and the gfxdriver will be requested to > present the new page (region). > What happens if DLCAPS_WINDOWS is set? Any caveats in using hardware > windowing?
As Ville already explained, in this mode the layer itself has no surface and the window buffers are all "known" to the hardware. If a new window is shown, the layer driver's AddRegion() and SetRegion() are called. Usually, only one region per layer is supported by hardware, but some support multiple regions, mostly not allowed to overlap or be on the same line at all. That means you can't have regions side by side in most of these hardware implementations. It depends on the application if this model is feasible, e.g. having different pixelformats, probably a bit less memory consumption and very fast moving of windows might be worth to follow the one-window-per-line rule. > Q. Currently I am setting DLCAPS_SURFACE and using surfaces for my layer > content. How would I provide my own content to a layer? Layers can have different "sources", i.e. their content, specified by their "source id". There's one predefined ID for a surface being the source. Others are provided by the driver. So far only a name and the source id are available. Applications can select between the sources by changing the layer configuration. > Specifically, I am considering how I might architect the following using > directFB: > > DirectFB > --> Layer1 (Surface) --> GfxDriver --> Screen > --> Layer2 (Surface) --> GfxDriver --> Screen > --> Layer3 (Surface) --> GfxDriver --> Screen > > In this set up I have a GUI that composites 3 layers. But Layer2 is to > contain a DRM surface. How do I attach my private surface to a layer? You provide your own source, not supporting the surface source at all is ok. Either you use the builtin surface management or have your own private API do everything. > To achieve this I'd (notionally) like to be able to create a CoreSurface > that represents a private allocation that is not managed by dfb's manager > and that is not valid for software read/writes. > I'd then like to 'attach' this to a layer such that my GfxDriver/Hardware > can resolve the arrangement while still preserving security on the Layer2 > contents. > Is this possible using existing interfaces? If not, is there any other > existing or better way to achieve this? I guess your questions are answered already, but correct me if anything is still not clear. I'm afraid I couldn't give an answer on your surface/driver extensions up til now. Did you do anything in that direction already? I'll give you a detailed answer tonight, but so far I'd like to encourage you to start with the changes you proposed, following your prefered choices. Maybe you didn't read about my redesign of the surface core that would allow many things like buffers not directly accessable (memory mapped), maintained by other libraries, like OpenGL or low level device drivers. If you have some ideas or would like to assist with the design and maybe even the implementation, I'd appreciate that. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
