[Mesa-dev] [GSOC] DriConf Replacement

Wed Apr 5 20:58:54 UTC 2017

On 05.04.2017 18:57, Jean Hertel wrote:
> 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.

There isn't a single place where their meaning is documented. The 
descriptive texts are usually quite self-explanatory, and where they 
aren't, you'd have to grep through Mesa to learn more.

Cheers,
Nicolai

>
>
> 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 <nhaehnle at gmail.com>
> *Enviado:* quarta-feira, 5 de abril de 2017 05:26
> *Para:* Jean Hertel; mesa-dev at 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 at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.