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

[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.

[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]

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 ?

[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.

[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.

[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.

[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 ?

[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.

[agd5f]

If you want something like this, it's something the Linux community needs to tackle in general. We used to support a settings GUI on fglrx and it was painful to support because every desktop environment stored display state differently and constantly changed their interfaces. Updates to GNOME or KDE broke the GUI constantly. Users would try to use the GUI on some slightly less mainstream desktops and it would not always work leading them to blame the driver rather than the desktop. Add the various wayland environments to the mix and things get even trickier.

[rene]

never understood the need of this windows style graphic setting ui, for professional use I vastly prefer software / driver properties and attributes, and tweaking /sys values, :_/