fjhenigman
commented
9 years ago I've been working on this and have enough to pass a chrome os test or two. It's by no means commit-ready, but I'll likely mail the waffle list next week asking for comments.
I named it WAFFLE_PLATFORM_NULL, because the gbm platform is not called EGL_GBM. I figured X11_EGL had the "EGL" in there to make it extra clear it wasn't glx. I have been trying to think of a different name however, because I put some stupid macro tricks into chrome os that trip up on NULL (because NULL is already a macro). That's not really a reason for a different name, but if someone suggests a good one I'll be all for it.
My goal was to make platform null a drop-in substitute for any other platform, so window_create works, swapbuffers works, everything works like in X or gbm. It actually didn't occur to me to go windowless/surfaceless. Doing so would mean re-coding any waffle program that wanted to work surfacelessly. However there are some major challenges in hiding the surfacelessness behind waffle. I'll elaborate when I ask for comments.
I've only tested with minigbm so far, but it seems like it should work with mesa gbm too. All it uses gbm for is to get and query buffers (and get corresponding dmabufs).
evelikov
Chrome OS Freon now uses the EGL null platform. Waffle needs a new platform type to support this. Otherwise, nothing works on Freon, not even wflinfo.
Difficulty: Easy but non-trivial.
The initial implementation should support waffle_config_choose and waffle_context_create. waffle_window_create can be implemented after context creation works. Or maybe waffle_window_create should never be implemented, always emitting an error on the EGL null platform. @fjhenigman is in the best position for deciding the behavior of waffle_window_create.
Questions