<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 11, 2016 at 3:43 PM, Chad Versace <<a href="mailto:chad.versace@intel.com" target="_blank">chad.versace@intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are two sets of very different json patchsets on the list. Each has advantages and disadvantages. Dylan's patchset duplicates a small amount of code. And it doesn't teach wflinfo to print any additional info, such as GLX or EGL specific info. However, the patchset is short, sweet, has no major flaw, and is the correct approach for what he wished to accomplish: teach wflinfo to print its current output in a new format, json. Having json output makes Dylan's life easier as a Piglit developer, and the sooner he can get json the better. So I'm inclined to expedite Dylan's patchset and merge it soon, pending fixes. Frank's patchset adds platform-specific info the wflinfo's output, which is a feature it really needs. And the code for the platform-specific info rightly belongs in core waffle, which the patchset gets right. However, the patchset is much larger, needs lots more review, and needs to undergo some API changes. In other words, Frank's patches will take more time to land, and Dylan's are nearly ready to land as-is. And I don't want to artificially stall Dylan's Piglit work. I've decided my preferred format for wflinfo's json output. If the format is acceptable to everyone, then I want to see Dylan fixup patch 4/4 of his series and resubmit. I've been taking notes on Frank's patchset, but won't have time to provide real feedback until Tuesday (tomorrow) morning. JSON Format ----------- Below is the json format I prefer. Is this acceptable to everyone? Did I underspecify the format? The major things I considered when deciding the format are: 1. Keep it simple. 2. Explicit is better than implicit. 3. Make life easy for existing wflinfo parsers that wish to begin consuming the json. That means existing keys and values should closely resemble eachother, and preferably be identical. Definition: * All key names are lower case, for consistency. * Key names use ' ', not '-' nor '_', as the separator. This is consistent with wflinfo's current output and glxinfo's output. * For existing keys in wflinfo's current output, the JSON key names should match modulo case. * For existing values in wflinfo's current output, the JSON value should be identical. * The "opengl" table contains all info specific to the OpenGL context. That includes GLSL info, as that is a property of the OpenGL context. { "waffle": { "platform": String, "api": String, }, "opengl": { "vendor string": String, "renderer string": String, "version string": String, "shading language version string": String, "extensions": [String], }, <if platform uses EGL> "egl": { "vendor string": String, "version string": String, "version": [Int, Int], "extensions": [String], "client apis": [String], }, <endif> <if platform is GLX> "glx": { "server": { "vendor string": String, "version string": String, "extensions string": [String], }, "client": { "vendor string": String, "version string": String, "extensions": [String], } "common": { "version": [Int, Int], "extensions": [String], }, }, <endif> } The GLX and EGL tables can be extended in the future to contain additional information, such as visual configs. </blockquote><div> </div><div>Your JSON format is fine with me.</div><div> </div><div>So if I understand, you're still interested in my patches after landing Dylan's? If so I'll just wait until all review comments are in (take your time) and then prepare v2. Thanks.</div></div> </div></div>