Frank, sorry the late reply. On Mon 30 Mar 2015, Frank Henigman wrote: > This patch set adds a new platform: WAFFLE_PLATFORM_NULL. > This platform uses EGL_PLATFORM_NULL, KHR_surfaceless_context, > EXT_image_dma_buf_import and gbm. > In this platform a waffle window contains gbm buffers and sets up > rendering into them via dmabuf, EGLImage and GL framebuffer. > These details are hidden from the user so the platform works exactly > like other waffle platforms. > It is also possible to show the gbm buffers on screen via DRM/KMS. > > Development ongoing at https://github.com/fjhenigman/waffle/tree/null. > The version here is tagged "null1" on github. > > Prerequisites: > - Mesa with gles2, intel, gbm (mesa gbm or minigbm) and these patches: > > https://raw.githubusercontent.com/fjhenigman/waffle/mesa/0001-egl-dri2-implement-platform_null.patch > > https://raw.githubusercontent.com/fjhenigman/waffle/mesa/10.3-i965-remove-read-only-restriction-of-imported-buffer.patch > > This is work in progress and numerous issues remain: > - display is upside down > - glBindFramebuffer(0) will not have the desired effect as the waffle > window uses non-zero framebuffers > - seems this can only be fixed for apps that use waffle to look up their > GL functions - by returning a wrapper to intercept glBindFramebuffer > - only GLES2 supported > - only double buffering supported > - only tested with Mesa/i965, and only on a couple simple Chrome OS tests > - should try a piglit run > - tested almost entirely with minigbm, barely with mesa gbm > - display works on i915 only > - i915-specific code is hard-wired - no graceful failure on other hardware > - minigbm might be a good place to stick hardware-specific code > - if we still want display for the GBM platform, we should try to share > display code with it > - errors are checked but some could be reported more informatively > - should fail gracefully in case of missing extensions > > Questions: > - instead of copying gbm buffers for display, can we use GL to draw a quad > using the source buffer as a texture?
Yes, that would be nice. > - can we then use render nodes to render to texture, and a master node only > to mode set and render to displayed buffer? Yes, that's a good idea too. > - this would make it simple to invert the currently upside down picture > - this could reduce or eliminate hardware-specific code > - can we do this in a separate context so as not to step on user's context? I believe a separate context will be required if Waffle makes any GL calls. > - should we load libdrm dynamically? I prefer that we do. That would allow a single build of Waffle to work on systems where the distributed libdrm does not include all libdrm "drivers" that Waffle was built against. > - should internal names have a wnull_ prefix for consistency with wegl and > wgbm? > - why the leading 'w?' The leading 'w' is to prevent namespace collisions with external libraries, collisions in readability and collisions during compilation. It should be clear in the code whether a symbol is defined by Waffle itself or if the is defined by the external dependency. This convention also prevents Waffle from accidentally overriding a symbol when linking to the external library. > - should we save/restore mode/crtc? > - seems vt doesn't come back after program exits, though it does after > changing to different vt and back I don't have a strong preference. - Pro: It's nice to the user when manually running a Waffle/NullPlatform app. - Con: The extra modesets could significantly slow down testruns, if the test run starts/stops many processes. > - how about a naming convention for selecting cards and connectors with > the argument to waffle_display_connect()? Do you have a concrete proposal for the convention? Would extending waffle_display_connect() to accept an attribute list help you achieve this? > - can/should we require waffle_window_show() be called before > waffle_make_current()? No. I'd like to maintain the ability to render to an unmapped window. > - would like know to if and how the window is going to be shown before > allocating buffers Can you solve this problem by definition additional attributes for waffle_window_create2()? _______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle