Hi guys, I would like to confirm what the actual long-term design intent of the CoreSurfaceAccessorIDs are. It appears that they now allow surface pools to report what specific display layer(s) they support and support associated querying/negotiation tasks, as well as for other potential special purposes (accelerators, DMA memory transfer related usage?). But, I do not see much coverage of the topic.
If so, it seems a step forward in reporting capabilities, but for layers does add some uncertainty... How should CSAID_LAYERx flags be interpreted by a surface buffer pool's lock function? As GPU or CPU? Previously, they received this information (set based on if it had DSCAPS_SYSTEMONLY set or not) and our custom DFB 1.2 display layer surface buffer pool lock would perform extra logic if the CPU was subsequently going to access the buffer memory (for reading and/or writing). Exactly when are the CSAID_LAYERx flags allowed/planned to be used/specified in a call to dfb_surface_buffer_lock? Currently, this only appears to be done when a display layer is configured or flipped (the entire surface using standard flipping not blit flipping). Also, I am curious what it means if a surface pool reports CSAID_ACCELx. Thanks, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
