search

ascent12 / drm_info

Moved to https://gitlab.freedesktop.org/emersion/drm_info
MIT License
63 stars 13 forks source link

Add JSON output support #17

Closed emersion closed 5 years ago

emersion commented 5 years ago

Seeking feedback.

Fixes https://github.com/ascent12/drm_info/issues/4

ascent12 commented 5 years ago

Is there a way to unify the regular output and the JSON output?

Maybe we could just make the regular output a consumer of the JSON output? It's slightly wasteful creating JSON structures to then not print JSON, but that's hardly a big deal and it already provides the tree for us.

Should we decode blobs?

Yeah, probably. It could just be some freeform "data" field of each property that needs it. Otherwise we'd need to include the raw data (as base64 or similar I guess), and parsing some of the fields is already weird enough (IN_FORMATS) and would make it more difficult to do anything useful with jq and that data.

LGTM so far.

emersion commented 5 years ago

Maybe we could just make the regular output a consumer of the JSON output? It's slightly wasteful creating JSON structures to then not print JSON, but that's hardly a big deal and it already provides the tree for us.

Yeah, that might be a good idea.

Yeah, probably. It could just be some freeform "data" field of each property that needs it. Otherwise we'd need to include the raw data (as base64 or similar I guess), and parsing some of the fields is already weird enough (IN_FORMATS) and would make it more difficult to do anything useful with jq and that data.

I wonder "how much" we should decode. Some things like properties flags (which include the type) and format fourcc codes are hard to consume with jq.

emersion commented 5 years ago

All right, the JSON side is mostly finished. I've decided to duplicate data when relevant, for instance each property has the raw flags but also some more convenient type, immutable and atomic fields.

I'll begin working on wiring up the pretty-printer.

emersion commented 5 years ago

BTW, I think both encoding the blobs in base64 and exposing a easy-to-use structure might be a good idea. This gives more freedom to consumers and allows them to parse blobs we don't support, such as the EDID.

emersion commented 5 years ago

All right, this is ready for review!

emersion commented 5 years ago

Makes sense, fixed

ascent12 commented 5 years ago

Thanks