On Sun, 28 Apr 2019 at 19:38, Jean Hertel <jean.her...@hotmail.com> wrote: > > >Could not find my original notes, but the idea is roughly as follows: > >- introduce a separate (user only?) library - say libmesa-config.so > > - ^^ provides an API to query/set attributes, via numerical tokens > > - any localisation is built on top of ^^ as standalone files > > > >Reasoning: > >- library reused by anyone to make a pretty config tool in their > >toolkit and/or language > > - numerical tokens are trivial to handle and cheap - can be > >binned/deprecated easily > > - translation lives outside of the driver - the driver doesn't care > >about it, so don't bloat > > - translators do not need access to mesa - one less hurdle/obstacle > > > > > >Hope it makes sense, not sure if coffee has kicked in fully ;-) > >-Emil > > Hey Emil, > > I really liked this idea, specially since right now I have a lot of issues to > query which option is exactly supported by each driver. Like in the scenarios > when you have multiple drivers that support the same GPU, or when you have a > difference between userspace and kernel space driver naming. > > Can you give me more details on the idea? > If I got it right, this library would be independent and mesa will itself use > it to query the options it wants/needs. > 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
> 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. > What about Vulkan? > As far as I known the current setup only handles OpenGL driver configurations. > The current setup handles GLX, DRI and Nine IIRC. One of my goals was to split and structure this in a more obvious way. HTH Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
