[waffle] [PATCH 00/10] null platform WIP

[Chad Versace]

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()?