[Mesa-dev] [GSOC] DriConf Replacement

Wed Apr 5 16:57:22 UTC 2017

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 <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170405/19ecb8bc/attachment-0001.html>