Nicolai,
Is there any place were I can find all the options with their respectives descriptions? I have readed a little of information about DRI here[1], but i'm not very sure were I can find a doc about all those options. About the language and the choice of full rewrite or incremental, I'm still thinking about it. Currently I don't know GTK+ and Python. C++ is a possible choice, as I already know a little about it. I'm studying the options and will see what best fits my knowledge. Best Regards [1]: https://dri.freedesktop.org/wiki/ConfigurationForDevelopers/ ________________________________ De: Nicolai Hähnle <nhaeh...@gmail.com> Enviado: quarta-feira, 5 de abril de 2017 05:26 Para: Jean Hertel; mesa-dev@lists.freedesktop.org Assunto: Re: [Mesa-dev] [GSOC] DriConf Replacement Hi Jean, On 04.04.2017 01:52, Jean Hertel wrote: > I would like to ask what are the proposed projects for Gsoc 2017. > Specifically I want to know if someone proposed something to the Driconf > replacement idea. If you haven't already, try installing driconf and playing around with it a bit. This should give you a reference point for how it works and the kind of complaints people have about driconf. Most of the user complaints are about the GUI being clunky and missing features. For example, it doesn't properly deal with the PRIME setups found in many laptops (internal GPU + external GPU). The way application-specific settings work is pretty weird as well: Why is it a separate pane of the window? From the Mesa developer point of view, there is one huge problem with driconf which means we must advise users against using it right now: It writes out a full ~/.drirc which overrides the system's /etc/drirc. So when a user runs driconf once and then later updates Mesa, the Mesa-provided /etc/drirc may have some changed options which are effectively ignored. Organizing a bit, here's a bunch of either smaller sub-projects to evolve the current DriConf, or things to keep in mind for a full re-design: 1) Change DriConf to not write the full ~/.drirc every time, but only the explicitly set options. DriConf should track options as "tri-state" (On/Off/System-default). 2) Handle the multi-GPU case. This requires some GUI changes, obviously. Under the hood, this requires directly enumerating the DRI device nodes and loading the driver for each device. 2b) Currently, devices are identified by driver name, which is a bit silly in A+A systems, where both the internal and the external GPU use radeonsi. Evolve the drirc XML format in a way to identify the actual device (by PCI ID makes the most sense, I think) instead of (possibly in addition to?) the driver. 2c) Consider adding an option to configure PRIME to driconf. [2b and 2c will also require changes in Mesa; also, you may want to get rid of the implicit dependency on xdriinfo] 3) Re-design the GUI in general, keeping in mind that it should provide a more natural way to define application-specific settings and driver-specific settings, and a combination of those. 4) There's just a general bunch of cleanups for user-friendliness that would be nice. For example, why is "Force GLSL extension default behavior to 'warn'" under the "Debugging" category, when it really should be under an "Application bug workaround" category? And options like "Force a default GLSL version" should provide a drop-down box of possible options rather than a generic integer slider. Note that many of these cleanups actually require changes to Mesa as well. This should give you a good idea of the kind of things that need to be taken into account. As for the replace/rewrite question: It's always tempting to say "I can do better, let's rewrite everything", and if you're "just" in it for the learning experience, then go for it! (This may be especially true if there's a different GUI toolkit that you know by heart or you hate Python; though I'd say that using a high-level language for GUI work does have an advantage.) However, think well about how much time you'll have to devote to this task. I would estimate multiple full-time months of work for addressing all of the above points properly. If you actually want to have a useful contribution in the end, it may be better and more rewarding to work on evolving the existing DriConf. Cheers, Nicolai > > Can anyone point me out? > > Thanks in advance. > > PS: I'm not elegible to the program, so please, don't reply saying that > the subscription time is over, I already know it. > -- > Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela > brevidade. > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
