[Mesa-dev] Move adriconf to mesa repositories

[Emil Velikov]

On Thu, 16 May 2019 at 10:59, Jean Hertel <jean.hertel at hotmail.com> wrote:
>
> On 8th May you Wrote:
> >Hi Emil,
> >
> >>This is the tricky part - wish I could find my notes they have better
> >>brain-dump.
> >>It's OK to have the library as both front (config tool) and backend
> >>(used by mesa) although:
> >> - special care on splitting and annotating the API is needed
> >> - handling this "extra" dependency would be fiddly for slower moving distros
> >>
> >I'm not sure I get the whole picture of what you are suggesting, so I put some ideas on how I think such API would work [here][1].
> >
> >>> What about the current configuration files? Do you think there is a better way to handle them?
> >>> They are for in a xml format, which is far from optimal.
> >>>
> >>What seems to be the problem with XML? The files are meant to be
> >>read/written to $app.
> >>
> >
> >I dislike XML because it is too ugly. Something more natural and easy to read/write would be more interesting.
> >Like a YML format. Ideally I would like to use JSON, but then it becomes a lot harder for people to write this by hand in case the GUI tools don't offer >the options they want/need.
> >Of course this is just my point of view, and not necessarily a real issue.
> >
> >Kind Regards,
> >Jean Hertel
> >
> >[1]: https://github.com/jlHertel/libdriconfig/blob/master/USAGE.md
>
> Hey Emil,
> Did you get a chance to look in my proposed way of building this new API?
>
> Some comments would be welcome.
> Also,  CC'ing Rob, as I think he would also have interest in this.
>
Had a quick look and noticed a few architectural nits.

I am a bit split between opaque structs vs not - slightly leaning
towards the former.
Reason being is that doing internal re-design becomes much easier and
we're baking less ABI into the users.

The following seems reasonable flow:
 - enumerate devices
   - query specifics - pci id/platform, memory, driver (kernel and/or
mesa), supported APIs (GLX,EGL,GBM, GL,GLES, NINE, VDPAU/OMX? Vulkan)
   - set specifics - mesa driver at least (think amdgpu vs amdgpu-pro
on same kernel module)
   [backend specific]
   - create device - sets the details ... APIs will be a bit fiddly
   - delete device - do we really need it? figure out the details

 - enumerate_apps/profiles (device) - there's special handle for the
global/default profile
   - query - name, executable, options
   - set
   [not backend specific]
   - create/delete
   - create_from_{global,other_profile)

- enumerate_options(device, API_MASK /* say GL_THREAD is GLX|EGL */, profile )
   - query_option - type/value
   - set_option - type(?)/value
   [backend specific]
   - create/delete


The tricky part wrt the fronend/backend mentioned earlier is that we
don't want !misc application to say "hey device/driver X can support
feature Y, on API Z".
Only the backend (mesa) is allowed to do that ;-)

HTH
Emil