LACT Is The Newest AMD Radeon GUI Control Panel For Linux

[GruenSein]

While I do have some sympathy for the accessibility argument (without having checked if it actually has any truth to it), I find the reactions here really fascinating. For years, Linux users have been asking for a GPU control panel for AMD GPUs. They asked AMD to port the Windows one to Linux etc. Now, that there is one by an independent developer that seems promising, it is disliked or even plainly rejected because of the toolkit it uses or maybe its button placement? How much time do you spent adjusting your GPU fan curve that this actually matters? Do you think any first party vendor would even take note of such criticisms? How does this really impact any potential user? Then again, there is always the option to go back to config files and the CLI... This kind of opinionated entitlement baffles me.

[AlanTuring69]

Dunce: I want a FOSS control panel for my graphics card.
FOSS developer: OK, here is a control panel for your graphics card. I spent my free time on this so I decided to use what I know and what most people that I know use, GTK4.
Dunce: TRASH@@@!!!!! I would NEVER use FOSS if it uses GTK4!!!!!!!!!!!
FOSS developer: Well then maybe you should consider writing one yourself?
Dunce: Why would I do that when I can just use other people's code and bitch about it? I submit constant feature requests so surely that's a contribution, right?
FOSS developer: .....

[Vistaus]

Dunce: I want a FOSS control panel for my graphics card.
FOSS developer: OK, here is a control panel for your graphics card. I spent my free time on this so I decided to use what I know and what most people that I know use, GTK4.
Dunce: TRASH@@@!!!!! I would NEVER use FOSS if it uses GTK4!!!!!!!!!!!
FOSS developer: Well then maybe you should consider writing one yourself?
Dunce: Why would I do that when I can just use other people's code and bitch about it? I submit constant feature requests so surely that's a contribution, right?
FOSS developer: .....

But still, if this was written in Qt, a lot of people would complain that it doesn't use GTK and b*tch about how much Qt sucks. If they are allowed to complain, then so are us KDE/Qt users when a GTK app is released.

[AlanTuring69]

But still, if this was written in Qt, a lot of people would complain that it doesn't use GTK and b*tch about how much Qt sucks. If they are allowed to complain, then so are us KDE/Qt users when a GTK app is released.

I have never once complained about a Qt app when using GTK. It really is not a big deal to use varying toolkits and I would make the same comment if it was inverted or using literally any other combination of anything in FOSS. I just happened to be looking at this thread right now.

Be thankful that there are people willing to spend time to open source their code and deal with people who complain about their free time being spent, or for corporate entities to contribute to open source projects.

[user1]

But still, if this was written in Qt, a lot of people would complain that it doesn't use GTK and b*tch about how much Qt sucks. If they are allowed to complain, then so are us KDE/Qt users when a GTK app is released.

At least if you're a KDE user, it's much easier to make them look like native Qt apps by using themes. AFAIK, The default Breeze theme even has it's own GTK variant. On the other hand, it's much harder for users of Gnome and other GTK desktop environments to make Qt apps look native.

I also don't understand these complains about the app using GTK 4 (at least if it's not regarding accessibility). Because by looking at it, it doesn't seem like it would really look different if it was written it Qt. I imagine it would have the same tabbed design and the only difference would be the use of server side decorations.

[schmidtbag]

As much as I dislike installing misfit toolkits, I've found it quite difficult to have a complete Linux desktop experience without having to install some sort of large dependency that only one application needs.
I've been saying for years that making an application like LACT isn't hard to do - it, like most other GTK and Qt apps, are just frontends to CLI tools. No offense to Ilya or the LACT team, but any amateur developer could make a tool like this. I'm honestly surprised it's taken this long for such a tool to be made. And no, I'm not saying LACT is amateurish, because it appears to be made quite well. I've considered making something like this myself, but, I just didn't care enough because I don't upgrade my GPU often enough to be a worthy maintainer.

[skeevy420]

While I do have some sympathy for the accessibility argument (without having checked if it actually has any truth to it), I find the reactions here really fascinating. For years, Linux users have been asking for a GPU control panel for AMD GPUs. They asked AMD to port the Windows one to Linux etc. Now, that there is one by an independent developer that seems promising, it is disliked or even plainly rejected because of the toolkit it uses or maybe its button placement? How much time do you spent adjusting your GPU fan curve that this actually matters? Do you think any first party vendor would even take note of such criticisms? How does this really impact any potential user? Then again, there is always the option to go back to config files and the CLI... This kind of opinionated entitlement baffles me.

FWIW, there are multiple control panels done in multiple UI toolkits by independent developers so, ideally, everyone should be covered and happy. None of those change the fact that there isn't anything official from AMD or Intel meaning that those projects are somewhere around bus factor 1 or 2 meaning that they aren't something to depend upon for long term usage.

That's why I tried to limit my comments above toward GTK and the HIG since that's what most people who dislike GTK programs dislike. I think LACT itself is a great looking option for people who like that sort of look.

I do all my fan curves in the UEFI. Set it once and it should work on any OS with worth-a-damn sensor support nor do I need some daemon running and eating up CPU cycles to do something it can do automagically with sensors. That said, fan curve options are nice when people buy Gateway's and other cheap-ass PCs that don't have worth-a-shit UEFIs or BIOSs so you're forced to run some daemon and eat up CPU cycles.

[kiffmet]

Looking good, but I'd much rather have a Qt or GTK3 based option, since those don't look alien on KDE. Having that said, CoreCtrl doesn't make me particularily happy either due to its interface design&layout. Since this is more of a nitty-gritty convenience kind of thing for me anyways, I'm completely fine having systemd start a user-service that fires up a self-made script which sets my OC on login, until something else comes around.

Overall, the emergence of this tool is definitely positive, and maybe someone will reuse the backend code (it's designed to do that using a json based command API and UNIX sockets, which is awesome!) and slap another GUI on top of it. So even if I'm not using it - thank you for your hard work, Ilya!

[gukin]

I was able to build and run 0.4.5 but I ran into problems compiling 0.5.0 and test, with a macro, I suspect my rust is a bit rusty.

Other than my inability to figure out my macro problem, 0.4.5 looked pretty good, it detected both the integrated Vega 8 5000 on my 5700g as well as my amazingly powerful RX 6400 and was able to show information and talk to both GPUs.

I thought it was a well designed interface and intuitive.

It would have been better if Motif had been used, those GUI toolkits from 35 years ago were the bomb!

[nadro]

Looks nice and for me GTK4 is a plus (personally I prefer GTK apps over Qt).