[waffle] [wflinfo] [RFC] platform-specific info from wflinfo

[Chad Versace]

On 02/17/2015 11:30 PM, Jordan Justen wrote:
> On 2015-02-10 12:09:05, Chad Versace wrote:
>>> On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote:
>>>> I'd like to extend wflinfo so it can print platform-specific
>>>> information and eventually be able to replace glxinfo, eglinfo and the
>>>> like (I only know what's on linux).  There would be a new flag to
>>>> request the platform-specific output in addition to the existing
>>>> output.  For example on glx you'd see glx extensions, on egl you'd see
>>>> egl extensions.
>>>> I've started two different implementations and I'd like to know which
>>>> is preferred before I go any farther.  Or if there's a better idea
>>>> than either of my approaches.  I've dubbed the two approaches "native"
>>>> and "core."
>>>>
>>>> native
>>>> - all the work is done in wflinfo, no changes to waffle api
>>>> - use waffle_display_get_native() to access platform-specific stuff
>>>> - pro: changes limited to wflinfo, doesn't clutter up the rest of waffle
>>>> - con: some duplicate code to open libraries and lookup symbols
>>>> - https://github.com/fjhenigman/waffle/tree/ps_native
>>>>
>>>> core
>>>> - add waffle_display_print_info() to waffle api
>>>> - add print_info() method to each platform
>>>> - pro: less code, no duplication
>>>> - con (perhaps): some wflinfo functionality is now in core waffle
>>>> - https://github.com/fjhenigman/waffle/tree/ps_core
>>>>
>>>> I'm leaning toward "core" because there is less code.  We get to
>>>> leverage the platform libraries and functions already stored in waffle
>>>> platform structs.  But if the consensus is it's cleaner to keep this
>>>> stuff in wflinfo I'm ok with that too.
>>
>> I prefer "core" too. Not for the sake of less code, but because I like
>> the idea of it being available as core API.
> 
> This surprised me a bit. I wouldn't think of the waffle library
> wanting to embed a bunch of strings to fulfill such an API.

Embedding string? I don't understand. Your proposal needs embedded
strings too: the strings for the key values.

If Waffle provides the display info in one big string or in a sequence
of little strings, as you propose, the same key strings need to be
embedded into the library. Am I missing something?

> Anyway... how about this:
> 
> char**
> waffle_display_info_strings(struct waffle_display *self, bool verbose);
> 
> The returned array of strings could have this property:
> 
> First look for a key string pointer. If it is NULL, then you are done.
> If you find non-NULL key string pointer then search for 0 or more
> non-NULL value string pointers. When a NULL pointer is seen, go back
> to looking for a key string pointer.
> 
> I've attached an example program that sort of emulates wflinfo...
> 
> This would allow the consumer to use comma separation and/or line
> breaks as desired.

For the sake of apps who want to dump the info to a log file or to
the console and get on
with their lives, I think the default output format should be a
single, giant string. But, as we're discovering in this conversation,
a single giant string might not be appropriate as a one-size-fits-all format.
I believe we can have it both ways, though, by adding some optional parameters
to the API.

  void*
  waffle_display_get_info(struct waffle_display *dpy,
                          enum waffle_display_info_format format,
                          uint32_t flags);

Then we have the ability to define API like this:

   // Returns a single, string suitable for log output. The return value
   // must be cast to `char*`. One valid flag is currently defined for this
   // format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT.
   waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0)

   // Returns Jordan array of strings. The return value must be cast to `char**`.
   // One valid flag is currently defined for this format,
   // WAFFLE_DISPLAY_INFO_VERBOSE_BIT.
   waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0);
   
   // Returns a JSON string. The return valud must be cast to `char*`. Two
   // flags are currently defined for this format: WAFFLE_DISPLAY_INFO_VERBOSE_BIT
   // and WAFFLE_DISPLAY_INFO_INDENT_BIT.
   waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0);

Of course, the "simple" and "jordan" formats will be the first ones implemented.
People can implement other formats in the future. (The JSON format, I'm just
using that as a hypothetical example.)

Do you think this is a good compromise between usability and extensibility? Does
my proposal lack some important knob you think is needed? Or is my proposal just
overall a bad idea?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/waffle/attachments/20150220/728db873/attachment.sig>