There's One Big Feature Left For The Radeon Linux Driver Left To Tackle In 2018

[duby229]

Why not just improve driconf ? It has been open source for almost 15 years, and the worst thing anyone seems to be able to say about it is "I don't like the way the GUI looks".

Oh that's just not true... You and I have have talked about this on this very forum, so that statement is a flat out lie.

EDIT: Yes it is true driconfs GUI sucks as, and yes that usually is the first complaint you hear. But that isn't it's problem. It doesn't do a ton of things a graphical control panel needs to do, like override antialiasing, or toggling the HUD, or graphing clock speeds, or configuring fan profiles, etc, etc, etc.... I mean really the list of all the things driconf -can't- do is long as fuck.

[bridgman]

Oh that's just not true... You and I have have talked about this on this very forum, so that statement is a flat out lie.

EDIT: Yes it is true driconfs GUI sucks as, and yes that usually is the first complaint you hear. But that isn't it's problem. It doesn't do a ton of things a graphical control panel needs to do, like override antialiasing, or toggling the HUD, or graphing clock speeds, or configuring fan profiles, etc, etc, etc.... I mean really the list of all the things driconf -can't- do is long as fuck.

Huh ? What did you think I meant by "improve" ? There is nothing in driconf that prevents it from being extended to include the features you mentioned - it's just python + GTK IIRC.

That said, almost everything you listed needs driver work first - the GUI is just the final step once the driver plumbing is in place.

EDIT - I did a bit of searching trying to find the earlier discussion about driconf you mentioned, but with no success. Can you point me to it please ?

[pcxmac]

I think a GUI is one of the last things AMD need to worry about. They still have a lot of work to do even in the Windows drivers department in terms of stability.

[duby229]

Huh ? What did you think I meant by "improve" ? There is nothing in driconf that prevents it from being extended to include the features you mentioned - it's just python + GTK IIRC.

That said, almost everything you listed needs driver work first - the GUI is just the final step once the driver plumbing is in place.

EDIT - I did a bit of searching trying to find the earlier discussion about driconf you mentioned, but with no success. Can you point me to it please ?

Arrgghhh, and you don't think that's the problem? So you say you know most of the things a GUI control panel needs are driver configuration. And you acknowledge that the drivers don't expose those configuration options. Oxymoron enough for you?

EDIT: The conclusion is and has been for well over a decade that configuration options valuable to a control panel simply don't exist. Or are not mesa configuration, like toggling tearfree or monitoring sensors and already have fragmented guis all over the place.

[duby229]

EDIT - I did a bit of searching trying to find the earlier discussion about driconf you mentioned, but with no success. Can you point me to it please ?

I can't find it either now. But we -did- have this conversation at least twice that I remember. You can't say you didn't know, you damn sure did know at least since something like 2010 or 11 or something like that.

[bridgman]

With respect, you still haven't identified anything wrong with driconf as a starting point for a GUI.

If we agree that continuing to work on getting the functionality implemented in the driver is a pre-requisite then why are we talking about GUI tools at all ?

[schmidtbag]

Why not just improve driconf ? It has been open source for almost 15 years, and the worst thing anyone seems to be able to say about it is "I don't like the way the GUI looks".

To my understanding, driconf only takes care of application-specific tweaks pertaining to only OpenGL. But I think people (such as Michael) are looking for things that are more specific to things such as the kernel, hardware, or the display itself, as well as ways to toggle experimental features. driconf is good but aside from being dated, it fulfills a different purpose that what people are asking for.

[bridgman]

Sure, every tool starts off doing the one thing it was first designed for.

I'm just saying "why not have one GUI" than writing something new and different for the functions that driconf doesn't handle today ? Whatever the new GUI is it'll probably end up just being another Python+GTK/QT thing anyways.

I've probably seen a dozen people post "well I would work on <GUI> but I don't know how to get started" just this year - and yet there is a working code base already there that would make a perfectly good starting point. The only reason it's dated is because nobody has felt it needed to be updated.