kfocus-power-bin does not work outside of Plasma

[eeickmeyer]

Describe the bug kfocus-power-bin does not function outside of plasma. When attempted to run inside of GNOME:

Output from terminal:

$ /usr/lib/kfocus/bin/kfocus-power-bin 
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QGuiApplication(0x7ffd0f83d540), parent's thread is QThread(0x556061b232c0), current thread is QThread(0x556061c05d90)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QGuiApplication(0x7ffd0f83d540), parent's thread is QThread(0x556061b232c0), current thread is QThread(0x556061c05d90)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is QGuiApplication(0x7ffd0f83d540), parent's thread is QThread(0x556061b232c0), current thread is QThread(0x556061c05d90)
QObject::installEventFilter(): Cannot filter events for objects in a different thread.
kf.kirigami: Failed to find a Kirigami platform plugin
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/InlineMessage.qml:257:13: QML SelectableLabel: Binding loop detected for property "implicitWidth"

It seems as though a dependency is missing.

To Reproduce Steps to reproduce the behavior:

1. Run kfocus-power-bin on GNOME (X11 or Wayland, doesn't matter)

Expected behavior Application should run properly.

Desktop (please complete the following information):

• OS: Ubuntu 22.04 (also run on 23.04 with success on Ubuntu Studio which is Plasma, so version doesn't matter in this case)

[ArrayBolt3]

Hmm, looks like I need to add kfocus-tools as a runtime dep.

[eeickmeyer]

Hmm, looks like I need to add kfocus-tools as a runtime dep.

I disagree. This is with kfocus-tools installed. kfocus-tools is merely a metapackage.

[ArrayBolt3]

Hrm. It looks like you're missing kfocus-power-set and kfocus-fan-set? Both of those are needed, so I assume one or both are missing.

[eeickmeyer]

Nope, I have both of them.

[ArrayBolt3]

Hmm, so on KDE, it does this in the terminal:

Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/templates/InlineMessage.qml:257:13: QML SelectableLabel: Binding loop detected for property "implicitWidth"

I know from experience that the Kirigami warning shouldn't affect functionality, but I notice that there are a few QObject errors in yours that aren't in mine. I wonder if that's the problem.

[ArrayBolt3]

Sheesh. In an Ubuntu Desktop 22.04 live env, my results are even more dismal:

qt.svg: Cannot open file '/usr/share/icons/hicolor/scalable/apps/kfocus-bug-power.svg', because: No such file or directory
qt.svg: Cannot open file '/usr/share/icons/hicolor/scalable/apps/kfocus-bug-power.svg', because: No such file or directory
QQmlApplicationEngine failed to load component
qrc:/main.qml:5:1: module "org.kde.plasma.core" is not installed
qrc:/main.qml:4:1: module "org.kde.kirigami" is not installed
qrc:/main.qml:3:1: module "QtQuick.Layouts" is not installed
qrc:/main.qml:2:1: module "QtQuick.Controls" is not installed
qrc:/main.qml:5:1: module "org.kde.plasma.core" is not installed
qrc:/main.qml:4:1: module "org.kde.kirigami" is not installed
qrc:/main.qml:3:1: module "QtQuick.Layouts" is not installed
qrc:/main.qml:2:1: module "QtQuick.Controls" is not installed
qrc:/main.qml:5:1: module "org.kde.plasma.core" is not installed
qrc:/main.qml:4:1: module "org.kde.kirigami" is not installed
qrc:/main.qml:3:1: module "QtQuick.Layouts" is not installed
qrc:/main.qml:2:1: module "QtQuick.Controls" is not installed
qrc:/main.qml:5:1: module "org.kde.plasma.core" is not installed
qrc:/main.qml:4:1: module "org.kde.kirigami" is not installed
qrc:/main.qml:3:1: module "QtQuick.Layouts" is not installed
qrc:/main.qml:2:1: module "QtQuick.Controls" is not installed

And the app doesn't launch at all.

[eeickmeyer]

Typically one needs to add the repository and install it properly. :)

[ArrayBolt3]

But I did though. Added the KFocus PPA, then ran "sudo apt install kfocus-power-bin". /me has never done this on GNOME before

[ArrayBolt3]

OK, found some missing deps and I can now reproduce this bug in a VM. Searching for the missing dependency now.

[ArrayBolt3]

The QObject stuff is a red herring. If I install GNOME and KDE on the same VM (don't ever do this outside a VM by the way, it will shred your desktop), the app works though the QObject errors are still present.

[ArrayBolt3]

After a long testing session between me and @eeickmeyer, it looks like we probably found the problem.

kfocus-power-bin uses PlasmaCore.DataSource to get data from kfocus-power-set and kfocus-fan-set, and to run them in order to change the state of the running system (by changing fan speed, for instance). This, I believe, introduces a hard depends on plasma-workspace.

plasma-workspace isn't exactly something you want to have installed on a GNOME system most likely, so probably adding it to the list of dependencies is not an ideal solution here, if it's a solution at all. So we'll probably have to find some way to replace PlasmaCore.DataSource.

[rikmills]

kfocus-power-bin uses PlasmaCore.DataSource to get data from kfocus-power-set and kfocus-fan-set, and to run them in order to change the state of the running system (by changing fan speed, for instance). This, I believe, introduces a hard depends on plasma-workspace.

It appears that plasma-framework has qml exports: ["org.kde.plasma.core/DataSource 2.0"], so it might be only that which is required.

[ArrayBolt3]

@rikmills That would be pretty convenient. Lemme test that and see what happens. I was going to rewrite the whole entire shell script management stuff in C++, which is less than easy.

[ArrayBolt3]

@rikmills Oh, I now see what you're saying, I misunderstood at first. Sadly, plasma-framework was not sufficient in my testing.

[ArrayBolt3]

Hey, wait a minute. We're importing PlasmaCore.DataSource 2.1. Not 2.0, which is what plasma-framework provides. If the program works with the downgraded version, that should do it.

[mmikowski]

Hi everyone!

The goal of kfocus-power redesign was to consolidate the all primary power controls into one rich and dynamic QML interface. It feels great to unplug a laptop and see almost all the power optimizations apply instantly. Once we add screen-brightness, I think it will be nearly complete.

Because of the QML interface, large parts of this should be easy to upstream to Plasma. In fact, the design technique used here could be the blueprint for future hardware-provided capabilities. The ability to use on other DEs was not a design constraint, although it would be great if that can be done with little effort.

If the front-end cannot be used by other DEs, the design implemented should be easy to copy to other front-ends such as GTK+ or even an electron client. Any solution should still be able to use the highly tested and maintained back-end scripts (kfocus-power-set, kfocus-fan-set) without modification. Even if they do eventually get rewritten in something besides bash, they would likely retain the same API as currently documented and tested.

Aaron, IMO, rewriting the backends so they are integrated into the power front-end really isn't an option. Critically, we call those APIs from multiple other scripts, and we don't want to maintain and align code and tests in two places. That could get very messy and expensive fast, and would probably make "native" ports to other DEs much harder.

[eeickmeyer]

Aaron, IMO, rewriting the backends so they are integrated into the power front-end really isn't an option. Critically, we call those APIs from multiple other scripts, and we don't want to maintain and align code and tests in two places. That could get very messy and expensive fast, and would probably make "native" ports to other DEs much harder.

That's not the goal. The issue was with how the frontend was interfacing with the backend bash scripts was relying on API calls specific to plasma-workspace itself. Those cease to function in other DEs, which is problematic for me when I'm trying to use my Kubuntu Focus M1 or XE when working in my wife's project: Edubuntu, which uses GNOME.

When I had written the kfocus-tools metapackage to begin with, I had written it with the specific intention that the tools could be installed in other DEs, even if we could not support the DE itself we could still support the tools because we had written them. Unfortunately, this tool now relies on a specific DE in order to function, which is problematic, and something we were trying to avoid.

So, what this means is that, because Edubuntu does not run Plasma is that the hardware controls do not work aside from the keyboard controls. No fan controls, no power controls. That's problematic.

And no, this cannot be upstreamed into Plasma because it's too hardware-specific to Kubuntu Focus laptops. The concept? Maybe, in which case they can pick-and-choose from the code if they so wish, but I cannot see this as something that will ever make it that far upstream.

[mmikowski]

Hi Erich! Because the backend APIs continue to function exactly as before, the prior front ends should still work. So you can snag them from prior commits and use them immediately. One could adjust to use these as a fallback when plasma capabilities are not present.

The goal of the unified power project was detailed in the spec which is as I recalled and does not specify cross-de support as an objective. We probably should migrate that doc to markdown here for reference. In any event, earlier front ends continue to work as discussed above.

As for upstreaming, the backends would need to be provided by a vendor, while the frontend could be incorporated to plasma. It is written in such a way so any number of values can be used, or entire capabilities omitted. There is already some interest, so we'll see how that goes.

[eeickmeyer]

Hi Mike, you're misunderstanding. The problem is in the QML where it's calling a plasma-specific API call to get the information from the shell scripts kfocus-power-set and kfocus-fan-set: PlasmaCore.DataSource. That API call is only in the package plasma-workspace which literally installs all of Plasma. This is causing the API calls to be completely missed by the frontend (it cannot get stdout from those scripts) and the result is in the screenshot posted up top. I assure you, I have those script installed and can easily set from the terminal, but that is far from ideal.

For what it's worth, I was able to install tuxedo-control-center which now includes keyboard backlight controls as an all-in-one solution, and it's completely DE agnostic, but I'd much rather have the solution(s) which we had developed.

[eeickmeyer]

I guess if we want to close this as "Won't fix: Not supported" I suppose we can, but that just means it's DE lock-in.

[mmikowski]

Hey Erich:

I'm not misunderstood, your assessment is exactly what I suspected. The architecture is also as we want it, I believe, with the single frontend and multiple backends.

There are two options to make the solution DE agnostic IMO:

1. Find a dbus-like mechanism to replace the plasma-specific call, or
2. Put the ui back into kfocus-fan and kfocus-power and then run that code instead when plasma is not available.

Another option which I believe Aaron was considering, was to integrate the backends into the QML code. However that is problematic as I discuss above. But option 1 or 2 should work without too much trouble.

[eeickmeyer]

Hi Mike,

That's not what Aaron was considering. He was looking for a C++ way to make the API call as opposed to relying on the Plasma library, essentially taking the C++ code that would be in the Plasma library and putting it in the code. That way the code wouldn't be relying on Plasma to get the stdout from kfocus-fan-set and kfocus-power-set.

Of course, this was determined in an IRC chat which didn't reflect here, so I see where you got the impression that he was working on integrating those two scripts into the QML code, which is not true.

[mmikowski]

Thanks for the clarifications Erich! While I think I understood the source of the problem, I certainly misunderstood the solution Aaron was considering which sounded like a whole lot of extra effort.

I looked at dbus-monitor and plasmaengineexplorer and it certainly looks like dbus is being used under the hood. So the replacing PlasmaCore.DataSource call with a dbus-native call might do the trick, but I certainly understand that can be far harder said than done since the Plasma method probably provides a whole bunch of convenience. OTOH, Nicco said it was deprecated in 6+, so I wonder what the preferred replacement is and whether it is DE agnostic.

Another option is to retain the prior GUIs and use them when a non-KDE desktop is detected. This is simple enough that it might be a quick solution before or until a dbus-native solution is available, and then nothing breaks, although the improved GUI isn't available (e.g. Plasma power profile, screen brightness). For example:

if [ "${_has_plasma}" = 'y' ]; then
  _runKfocusPowerBinFn;
else
  _showLegacyGuiFn;
fi

In any event, I think it is certainly worth keeping this open until it is either implemented or we determine it is too expensive to pursue. We could setup a separate branch to explore...

[ArrayBolt3]

Just seeing this now (just got back from celebrating Passover).

@mmikowski Actually, my intention was to just implement a "shell script runner" in C++ (which should be nearly trivial if I can ever figure out how to use Qt right). Then I can make that available to Qt and be able to call shell scripts and read their stdout from within QML. All that we need is to be able to tell it "Hey, run this, and tell me what it spit back out." Certainly we don't need to depend on an entire DE just to do that - this is a native capability of many (possibly most?) major languages. The only tricky part here is figuring out how to get C++ and QML to talk to each other (which is something Qt supports natively), and the only reason that's hard is because I've not done it before - it's probably quite easy in practice and I just need to get the hang of using a new tool.

[mmikowski]

Happy Passover Aaron! I hope you and your family had a great holiday. We had bunnies here :)

I agree that the shell-script-runner is good. I suspect there is a standard library for that, especially since PlasmaCore.DataSource is deprecated in Plasma 6+ (per Nicco). I dropped a note on IRC #plasma but haven't seen anything yet.

Related: I'm working on adding the display brightness slider to the tool, and also auto-applying powersave when the user unplugs to battery. Implementation is a WIP.

[mmikowski]

For some reason, the PR did NOT merge into the default branch (JJ-2023-04) even though this IS listed as the base branch. I will need to figure out why later, but this explains why the latest beta doesn't work outside of plasma.

[mmikowski]

The merge is there, but somehow the changes got removed. Not sure how.

git checkout JJ-2023-04 && git log # Shows the merge from Aaron's branch 3bb1bb73
git log package-power-bin/main.cpp # Commits are missing!

# But we CAN see the commits here:
git log 3bb1bb7 package-power-bin/main.cpp

I can recover by diffing the commit, but I'm still flummoxed about how the changes got lost. Any ideas?

[mmikowski]

@eeickmeyer and @ArrayBolt3: All the changes have been merged and then pushed. Run sudo add-apt-repository ppa:kfocus-team/package-testing to see the changes. We are testing on 6 devices, but additional feedback is welcome.

Besides the cross-platform capability, also fixed was some string handling for fan status, and the frequency selector no longer tends to reset itself during polling - this was a race condition that is now mostly resolved.

Since the testing and is nearly done and looks good, I will close this for now. If you see any issues in your experience, please let me know.

Aaron, thank you for all your hard work on getting this implemented.